Visa Test Tool Technical Requirements for Reader Test Plans
Version 3.5 | Oct 2025
Important Note on Confidentiality, Disclaimers and Copyright
© 2025 Visa. All Rights Reserved.
Confidentiality: This document, and the information set out in this document, is proprietary and CONFIDENTIAL to Visa. It is distributed to you by Visa as a participant in the Visa payments system for your use only to the extent necessary to enable Visa programs. You acknowledge that the information contained herein (the 'Information') is confidential and subject to confidentiality restrictions contained in Visa's operating regulations or other confidentiality agreements that limit your use of the Information. In no event may this document or its information be duplicated, published, distributed, or disclosed, in whole or in part, to any third party, individual, or any other person, without prior written permission from Visa, and without expressly limiting by way of contract that person's use of this document and the information it contains to assisting you in managing your Visa programs. This document and the information set out in this document may not be used in connection with, or to support, any non-Visa programs or any non-Visa payment network, system, or scheme, including any non-Visa program that is co-badged or co-resident with a Visa program, in each case, without Visa's prior written consent.
Trademarks: The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively the "Trademarks") are Trademarks owned by Visa. All other trademarks not attributed to Visa are the property of their respective owners.
THIS PUBLICATION IS PROVIDED ON AN "AS IS", "WHERE IS", BASIS, "WITH ALL FAULTS" KNOWN AND UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE LICENSED WORK AND TITLES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.
THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE MAINTAINED IN CONFIDENCE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE SPECIFICATION LICENSE OR OTHER WRITTEN AGREEMENT BETWEEN YOU AND VISA INC., VISA INTERNATIONAL SERVICE ASSOCIATION, AND/OR VISA EUROPE LIMITED.
Table of Contents
- Introduction
- 1. Overview
- 2 ICS Form Entry
- 3 Test Case Filtering
- 3.1 Test Case Generation Concept
- 3.2 Product Provider's Input
- 3.3 Filtering Rules
- 3.4 Filtering Method
- 3.5 Exemption List
- 3.6 Visa Test Case Filtering Report Generation
- 3.7 Using the ICS Schema
- 4 Test Case Execution
- 5 Manual Test Plan
- 6 VRTPKS Test Plan (Tap-to-Phone)
- 7 VTTCD Test Plan (Tap-to-Consumer-Device)
- 8 VCTKS Test Plan (Visa Contactless Transit Kernel)
- Appendix A Test Message
- A.1 Overview
- A.2 HTTP Message
- A.3 Start of Transaction (STXN)
- A.4 End of Transaction (EXTN)
- A.5 ECHO
- A.6 Scenarios and Error Handling
- A.6.1 General - No Host Response
- A.6.2 General - Bad Request Format
- A.6.3 General - Server Busy, Request Timeout
- A.6.4 General - Error Message
- A.6.5 Connection and Messaging Protocol Test
- A.6.6 Test Execution
- A.6.7. Test Execution - Stop on Error
- A.6.8 Multiple Start of Transaction (STXN) Messages
- A.6.9 Multiple End of Transaction (ETXN) Messages
- A.6.10 End of Transaction (ETXN) Message with Wrong Test_ID
- A.6.11 Echo in Between Messages
- A.6.12 Unexpected Flow of Message
- Appendix B Reader Status and Event
- Appendix C Keys Information
- Appendix D Additional Information
- Appendix E Kernel 8
- Appendix F Report XML File
Version History
This document provides information on how to process Visa’s machine-generated Test Plans. Tool Vendor shall implement the requirements into their Tool development.
| Version Number | Date | Description |
|---|---|---|
| 1.0 | December 2017 | First Publication |
| 1.1 | April 2018 | Removed the chapter related to Output files Renamed Supplementary to Manual |
| 1.2 | July 2018 | Updated ETXN to add Acquirer Data, IRWIN Data Updated Appendix D Updated for VOQOS test plan execution |
| 1.3 | December 2018 | Section A.2
|
| 1.4 | January 2019 | Section 5.2.2
|
| 1.5 | March 2019 | Appendix B.2
|
| 1.6 | April 2019 | Table A-3 and Table A-7
|
| 1.7 | August 2019 | 5.2.2 Emulation Requirements (Manual Test Plan)
|
| 1.8 | May 2020 | Reference added to VRTPKS (Visa Ready Tap to Phone Kernel Specification) and VRTPKS Test Plan v1.0a Chapter 6. General Notes added for VRTPKS Test Plan |
| 1.9 | March 2021 | Section 4.5.3 and 4.5.4
|
| 1.10 | October 2021 | Table 4-5
|
| 3.0 | April 2024 |
|
| 3.1 | May 2024 | Reference added to VTTOD (Visa Tap to Own Device Kernel Specification) and VTTOD Test Plan Chapter 7. General Notes added for VTTOD Test Plan Other Events
|
| 3.2 | June 2024 | Renamed “VTTOD” to “VTTCD” and “Tap to Own Device” to “Tap to Consumer Device” Other Events
|
| 3.3 | Feb 2025 | References added for VCTKS (Visa Contactless Transit Kernel Specification) and VCTKS Test Plan Chapter 3: Test Case Filtering
|
| 3.4 | March 2025 | 5.2.2 Emulation Requirements
|
| 3.5 | Oct 2025 |
|
Introduction
The Reader/Terminal Test Plan(s) is a resultant of Visa's initiative to encourage test automation. This document describes the architecture needed for Test Tools to execute Visa’s Level-2 Device Type Approvals.
With the logic in place, automated test case filtering, test execution and test validation is now possible.
This document provides information of how the Test Plan materials shall be used and the technical requirements for Test Tools in order to achieve the automation required.
General Information
Audience
This document is intended for Test Tool Vendors that are seeking or to maintain Visa recognition of their test tools.
Scope
This document describes the rules of test case filtering with a high level of background information on related test documents. Additional information is made available for the audience to interpret the test materials/parameters and to allow for tool customization which is required for test execution.
Reference Materials
The following documents are referenced in this specification.
| Reference | Document |
|---|---|
| VCPS | Visa Contactless Payment Specification (VCPS), Version 2.2, January 2016 – Visa Supplemental Requirements and all latest updates |
| VCPS 3.0 | Visa Contactless Payment Specification (VCPS) Card Specification, Version 3.0 – Visa Supplemental Requirements and all latest updates |
| VCPS APP SELECTION | Visa Contactless Payment Specification (VCPS) Reader Application Selection Specification, Version 3.0 and all latest updates/bulletins |
| VCTKS | Visa Contactless Transit Kernel Specification (VCTKS), Version 1.1 and all future updates |
| VRTPKS | Visa Ready Tap to Phone Kernel Specification (VRTPKS), Version 1.2 and all future updates |
| VTTCD | Visa Tap to Consumer Device Kernel Specification (VTTCD) Version 1.1 and all future updates |
| VCPS Reader Test Plan | VCPS Reader Test Plan Package Version 2.2x consists of:
|
| VCTKS Test Plan | VCTKS Test Plan Package consists of:
|
| VRTPKS Test Plan | VRTPKS Test Plans |
| VTTCD Test Plan | VTTCD Test Plans |
| Companion Guide | VCPS Reader Test Plan Companion Guide for Test Automation VRTPKS Test Plan Companion Guide for Test Automation VTTCD Test Plan Companion Guide for Test Automation VCTKS Test Plan Companion Guide for Test Automation |
| TermSIM Guide | TermSIM User Guide latest version |
| EMV Book 2 | EMV Book 2 – Security and Key Management Version 4.4 and all future updates |
| C8 | Book C-8 Kernel 8 Specification Version 1.1 and all future updates |
| Digital Report | Visa Digital Report Requirements, Version 1.0 and all published versions |
Glossary
| Acronym | Definition |
|---|---|
| Type Approval | Verification by Visa that a specific product has demonstrated sufficient conformance to the Visa specifications |
| Product Provider | The entity that submits a Visa product to Visa for Type Approval. |
| Test Case | A description of the actions required to achieve a specific test objective. |
| Test Tool Vendor | An entity that submits a test tool to Visa for validation. |
Terminology and Conventions
Many of the definitions, acronyms, and notations in this document are new with contactless technology or are based on contact chip technology (EMV). This document assumes a level of familiarity with both contactless technology and EMV. For those who are less familiar, this explanation of terms and conventions is placed early in the document for your reference.
- ICS – Implementation Conformance System
- fDDA – Fast Dynamic Data Authentication
- EMV – Europay, MasterCard, Visa
- SDA – Static Data Authentication
- ART – Application Requirements Testing
- ECC – Elliptic Curve Cryptography
- RC – Reader Controller
- K8 – Kernel 8
Materials Included in Test Package
This section describes the materials included in the test plan. This includes (but not limited to) the following files:
-
test_case.html
Documents a test case with high-level information of the test case overview, test instructions, reader-terminal configurations, and test procedures.
-
test_cases_targets.xml
Provides a minimum highlight on the scope or objective of each test case
-
index.html
Index home page of the test plan. Contains hyperlink to all test cases and release note.
-
release_notes.html
Contains the test plan revision history.
-
ics_<running number>.xml
Contains the ICS configurations; describes the requirement for each feature for the corresponding test case(s) that is (are) using this xml
-
ics_mapping.xml
Provides a list of test cases that are grouped based on the support of same set of Optional Features used
-
filtering_exemption.xml
List the test cases that are to be excluded for test execution depending on the ICS feature supported. This file is further described in 3.5 Exemption List.
-
transaction_<test case>.xml
Contains the transaction configuration, test instructions, transaction APDUs and expected final transaction outcome of each test case.
-
config_<running number>.xml
Describes the testing configuration and reader-terminal configurations necessary to perform a test.
-
config_mapping.xml
Provides a list of test cases that are grouped together based on the same set of config_<running number>. Useful for grouping runs during test execution.
-
sim_config_list.xml
Lists the corresponding configuration on the Visa Simulator (i.e. TermSIM) required for each test case. This list is only intended when using the Visa Simulator. For more information on the Visa Simulator’s configuration, please refer to the TermSIM Guide.
-
visual_list.xml
Contains list of payment (retail/transit) test cases that requires extra handling (i.e. visual inspection) and user confirmation in Automated testing mode.
-
ca_keys.xml
List of Certificate Authority Public keys that is used by the Reader/Terminal for Offline Data Authentication. Refer to C.2 CA Keys for details.
-
icc_keys.xml
List of keys (RSA/ECC Private Key) used by the card for dynamic Signed Dynamic Application Data (SDAD) generation (RSA) in qVSDC transaction and dynamic Card Key Data generation (ECC) in K8 transaction. These keys are referenced from transaction_<test case>.xml and is useful for Card Emulation. Refer to Appendix C.1 ICC Private Keys for details.
-
regression_list.xml
List of test cases in scope to test for regression. This list is only used when the product-under-test is allowed to run in regression mode.
1. Overview
1.1 Automation Setup (Automated Testing)
This figure describes the role of 3 entities in test automation:
- Test Tool
- Reader Controller (provided by the product vendor)
- Physical Reader (product-under-test)
On a high level, the Test Tool:
- Communicates with the Reader Controller to deliver transaction configurations and receive transaction outcomes.
- Provides card emulation of any form (e.g. via card probe or via physical card) that is to be used for each test case execution.
- Provides UI guidance to the test executor such as:
- ICS declaration form entry
- Displaying test steps and instructions to perform a test
- Displaying user prompts to confirm status, events and visual checks
- Displaying the test verdict
- Validate the APDUs and transaction outcomes
On a high level, the Reader Controller:
- Communicates with the Test Tool to receive the transaction configuration and pass it to the Physical Reader.
- Note: Transaction Configuration in this figure represents the content of Start-of-Transaction message response as described in Appendix A
- Retrieves the Transaction Outcome from the Physical Reader and subsequently submit this information to the Test Tool.
- Note: Transaction Outcome in this figure represents the content of End-of-Transaction message request as described in Appendix A
On a high level, the Physical Reader/Terminal (i.e. product-under-test):
- Communicates with the Reader Controller to receive transaction configuration
- Note: Transaction Configuration in this figure represents the content of Start-of-Transaction message response as described in Appendix A
- Performs transaction based on the transaction configuration
- Submits transaction outcome to the Reader Controller
- Note: Transaction Outcome in this figure represents the content of End-of-Transaction message request as described in Appendix A
Both the Test Tool and Reader Controller follows the Test Message protocol as defined in Appendix A Test Message.
Messaging between the Reader Controller and the Physical Reader is vendor proprietary and is out of scope from this document.
Note: In the best scenario, test automation is always preferred and much sought. Automation cuts human errors, optimizes testing strategy and significantly reduce testing times. However, in a situation where a Product Vendor choose not to conform to the test automation requirements as stated in the Companion Guide, the test tool shall be able to run the test plan in Regular mode (manual execution).
1.2 Test Process
Description: This figure illustrates the high-level logical steps required to build a Visa approved test tool with reference to this document.
*For TermSIM configuration, when running Test Tools with TermSIM
2 ICS Form Entry
A User interface shall be provided by the Test Tools for Product Providers to indicate the Optional features supported by the Reader/Terminal subject for testing. This information will eventually be the input data for test filtering and test execution discussed in Section 3 Test Case Filtering and Section 4 Test Case Execution.
Sample UI (for illustration only):
Note: Each item feature will have a corresponding parameter i.e. [OPT_xxx] which is used and recognized by the test tool. This information will be used to assess the applicability of each test case and will be detailed in the next section. The full list of Optional Features questions and its corresponding [OPT_xxx] is described in the 3.7.2 ICS Mapping Information of the ICS Schema File.
3 Test Case Filtering
3.1 Test Case Generation Concept
Each test case is developed specifically to test supported feature(s). Therefore, most of the test cases will specify the feature(s) under test to be 'TRUE' for test execution. In order to reduce dependency of other non-tested features in a test, the rest of the features, which are independent of the test objective, will be defaulted to a ‘FALSE’ (with related data not configured in reader-terminal parameters).
Note: In a test case, if a feature is set to 'FALSE', it does not imply that the product-under-test does not support that feature. It merely indicates that the feature is not the “feature-under-test” for this test case
Example: Test Case 001 checks Issuer Update Processing feature
- Requirement stated in the test case shall be: OPT_CONTACTLESS_ISSUER_UPDATE_PROCESSING_SUPPORTED is 'True'
- The rest of the features, for example OPT_ONLINE_PIN_SUPPORTED will be set to 'False' as these are not the “feature-under-test” for this test case. By doing so, Test Case 001 can be assessed independently, regardless of the support for other features in the implementation
- Only test parameters specific to this test will need to be configured. In this case, the Expected Host Response (Authorization Response Code, Issuer Authentication Data, and/or Issuer Scripts) needs to be defined. For non-Issuer-Update-Processing related test cases, the Expected Host Response are not configured since it is not the “feature-under-test”
In general, a product that supports Issuer Update Processing (regardless of the support for Online PIN) must run Test Case 001. Only in the event that the product does not support Issuer Update Processing, Test Case 001 can be marked as Non-Applicable and not be executed by the Test Tool.
3.2 Product Provider's Input
Product Provider will be prompted to indicate the features supported by their product as described in Section 2 ICS Form Entry. The Optional Features support declaration are mapped accordingly to the corresponding parameter (i.e. [OPT_xxx]) listed in the ics_<running number>.xml.
Based on the selection of the Optional Features supported, Test Tool Vendor shall be able to filter and exclude non-applicable test cases with each corresponding parameter for the test product.
Note: Test Tool Vendor shall also support the import and utilization of the Digital ICS XML file as defined in the Digital Report, if provided. The Digital ICS XML file contains the details of the product's declaration for the supported features and it shall be used in a similar manner to an ICS form.
3.3 Filtering Rules
Coupling the information from Sections 3.1 & 3.2, the filtering logic is generally dependent on the Optional Features support declaration by the Product Provider. Each and every feature shall be assessed with the following rules:
- If the feature is supported (‘YES’) by the Product Provider, none of the test cases shall be excluded*
- If the feature is not supported (‘NO’) by the Product Provider, any test case that has the corresponding Tag (i.e. OPT_XXX) defined as ‘True’ shall be excluded for test execution. And any test case that has the corresponding Tag (i.e. OPT_XXX) defined as ‘False’ shall be included for test execution.
Example using a Matrix Tabulation of Rule 1 & 2:
Note: There is a handful of tests that is genuinely testing with OPT_XXX == ‘False’ and will be specially identified in a list (Refer to 3.5 Exemption List) for Test Tool Vendors to exclude these tests when Product Provider supports these feature(s).
Online and Offline Capabilities: Do note that the options OPT_ONLINE_CAPABLE and OPT_OFFLINE_CAPABLE are referenced more than once in different GUI Parameters (GUI_BOTH_ONLINE_OFFLINE_CAPABLE, GUI_ONLINE_ONLY, and GUI_OFFLINE_ONLY). Ensure that when an OPT is set to a “True”, it will not be overwritten by “False” when referenced again in a different parameter.
| Feature | GUI Parameter | ICS Parameter | Answer |
|---|---|---|---|
| 1) The device supports both online capable and offline capable? | GUI_BOTH_ONLINE_OFFLINE_CAPABLE | OPT_ONLINE_CAPABLE OPT_OFFLINE_CAPABLE |
Yes |
| 2) The device supports online only? | GUI_ONLINE_ONLY | OPT_ONLINE_ONLY OPT_ONLINE_CAPABLE |
No |
| 3) The device supports offline only? | GUI_OFFLINE_ONLY | OPT_OFFLINE_ONLY OPT_OFFLINE_CAPABLE |
Yes |
In this example, where Features 1 and 3 are supported and Feature 2 is not supported; Feature 1 sets OPT_ONLINE_CAPABLE == “True” and shall remain to be a “True” after evaluating Feature 2.
3.4 Filtering Method
With the filtering rules in place, this section details how each feature is being assessed with the provided test package. For a better illustration, an example of generated test cases is used and the information from Product Provider’s Optional Features support declaration, ics_<running number>.xml and ICS_Mapping.xml are used for filtering assessment.
Optional Features Support Declaration by Product Provider:
- Issuer Update Processing is not supported;
- Rest of the features are supported
ics_<running_number>.xml: A set of xml files will be generated from the test cases and each of these ics_<running number>.xml contains a specific set of Optional Features support configurations. For example, we have two generated xml files: ics_1.xml which does not support Issuer Update Processing but supports Online PIN and ics_2.xml which supports Issuer Update Processing but does not support Online PIN respectively:
ics_1.xml: OPT_CONTACTLESS_ISSUER_UPDATE_PROCESSING_SUPPORTED indicates a ‘True’ => testing with Issuer Update Processing feature set and Online PIN feature not set
<ics_element>
<code> OPT_CONTACTLESS_ISSUER_UPDATE_PROCESSING_SUPPORTED </code>
<value>True</value>
</ics_element>
<ics_element>
<code>OPT_ONLINE_PIN_SUPPORTED</code>
<value>False</value>
</ics_element>
ics_2.xml: OPT_CONTACTLESS_ISSUER_UPDATE_PROCESSING_SUPPORTED indicates a ‘False’ => testing with Online PIN feature set and Issuer Update Processing feature not set
<ics_element>
<code> OPT_CONTACTLESS_ISSUER_UPDATE_PROCESSING_SUPPORTED </code>
<value>False</value>
</ics_element>
<ics_element>
<code>OPT_ONLINE_PIN_SUPPORTED</code>
<value>True</value>
</ics_element>
Test cases that has the same ICS configurations are grouped accordingly under the corresponding ics_<running number>.xml and this information is available in ICS_Mapping.xml.
ICS_Mapping.xml:
Test cases are grouped together by features (ICS). Example: 'ics_1.xml' has corresponding test case 'T_5_93_C04_001' on non-Online PIN, Issuer Update Processing related tests; while 'ics_2.xml' has corresponding test case 'T_5_79_C04_001' on non-Issuer Update Processing, Online PIN related tests
<ICS_Mapping>
<ICS ID="ics_1">
<TestCase>T_5_93_C04_001</TestCase>
</ICS>
<ICS ID="ics_2">
<TestCase>T_5_79_C04_001</TestCase>
</ICS>
</ICS_Mapping>
Filtering Assessment:
From the above scenario, Product Provider does not support Issuer Update Processing and therefore will not be required to execute test case 'T_5_93_C04_001' since this test has a requirement for Issuer Update Processing support to be 'True'. For the rest of the features that are supported by the Product Provider, no filtering is required since all of the other cases (except for those that has been already excluded by the filtering method) will be valid.
3.5 Exemption List
As mentioned in Section 3.3, there exists test cases that aims to check for the non-support of certain feature(s). These test cases should be deemed as 'Non-Applicable' for test execution if the Product Provider indicates support for the respective feature specified in the test case. This section shall only be considered after filtering assessment has been applied to each feature as described in Section 3.4 Filtering Method.
A filtering_exemption.xml file is included in the Test Package and this file is an extension to the filtering logic described in the previous sections.
The filtering_exemption.xml lists the test cases to be excluded for test execution. These test cases are linked to a specific Optional Features support declared. If Product Provider declares support for the feature(s) in the xml, the corresponding test cases shall be excluded for test execution.
In an example of a filtering_exemption.xml file below:
<ExemptionList>
<Rule Description="OPT_ONLINE_PIN_SUPPORTED=True">
<TestCase>T_5_79_C10_001</TestCase>
<TestCase>T_5_79_C10_002</TestCase>
</Rule>
<Rule Description=…>
<TestCase>…</TestCase>
</ExemptionList>
Each <Rule Description> attribute denotes the condition for each of the <TestCase> under which to be excluded for test execution. For instance, if Product Provider indicates support for 'Online PIN' (OPT_ONLINE_PIN_SUPPORTED) then T_5_79_C10_001 and T_5_79_C10_002 shall be excluded for test execution.
Note: There can be more than one Rule indicated and there can be more than one Test Case under each Rule stated in the XML file.
3.6 Visa Test Case Filtering Report Generation
This section describes a mandatory feature to be implemented by the Test Tools to provide an automated mechanism for Visa to perform Test Case Filtering validation.
This feature requires a generation of a Test Case Filtering Report in XML format.
The report will serve as a standard input to Visa’s in-house application to validate the accuracy of the tools’ test scoping results.
3.6.1 Report Generation
It is mandatory for Test Tools to provide a means for user to generate Test Case Filtering Report(s) within and outside a usual test session.
While mandatory, this feature is not a requirement in performing a test session.
3.6.2 Procedure
The overall procedure for the Test Case Filtering validation using Visa’s in-house application.
Important: The diagram is not intended to specify the architecture, design, or implementation of this feature in the test tool, Test Tools are free to define their own method for better usability. The procedures described here simply provides a context for understanding how the system works together to achieve the testing requirements.
3.6.3 Test Case Filtering Report
The guideline in this section ensures that the Test Case Filtering report output is standardized across different test tools.
Test Tool providers shall use the accompanying XSD schema to ensure the accuracy of the report.
The sections with XML tables describe the various elements within the XML and their requirements, as detailed in the schema.
3.6.3.1 File Format and Naming Convention
Test Tool shall generate a Test Case Filtering Report in XML format and following the file naming convention:
Report_ICS_["VTF#"]_[Timestamp].xml
Where:
- Report_ICS – is a static prefix name.
- {VTF#} is the product’s assigned VTF number, such as “CDVISA01234A” or “LBVISA01234A”
- {Timestamp} represent the time when the report is generated in UTC time format: YYYYMMDDHHMM. For example, “202501151525”.
- YYYY: 4-digit of the year
- MM: 2-digit month of the year
- DD: 2-digit day of the year
- HH: 2-digit hour using a 24-hour clock
- MM: 2-digit minute
Note: All spaces " " and any special characters (not 0-9, A-Z) shall be replaced by an underscore "_". E.g., Report_ICS_LBVISA01234A_240918145415.xml
3.6.3.2 Schema Definition
An accompanying schema file will be provided in the test plan, within the "schema" folder. This schema conforms to the W3C XML Schema Definition Language (XSD).
The schema for the Test Case Filtering Report is named as such:
- TestCaseFilteringReportSchema#_#.xsd
Filename begins with “TestCaseFilteringReportSchema” where "#_#"" is the major and minor version number.
3.6.3.3 Populating Schema File Name
Test tool providers are required to pick the correct schema for use, and populate the corresponding schema file in the attribute of the Root Element of the XML format as such:
<TestCaseFilteringReport xsi:noNamespaceSchemaLocation="TestCaseFilteringReportSchema1_0.xsd">…</TestCaseFilteringReport>
3.6.3.4 Schema Validation
The report shall be validated against the accompanying [TestCaseFilteringReportSchema_File] to ensure the accuracy of the XML structure.
3.6.3.5 Report XML File Structure
To allow uniform parsing, each XML file shall begin with a XML prolog, indicating an encoding of "UTF-8" or "utf-8".
E.g.:<?xml version="1.0" encoding="UTF-8"?>
All elements, attributes and defined values used in the Tables are case-sensitive unless otherwise stated. The order of the occurrence of the elements or attributes is unimportant unless otherwise stated. Whitespace between tags is ignored as is leading and trailing whitespace for a tag’s value. Values that are of Hexadecimal String shall be in upper case and without whitespaces.
3.6.3.6 Test Plan Information
The tools shall store the test plan information such as the Official test plan package name as received from Visa, and by examining the content of [PackageName]/data/test_plan.js.
E.g. content of test_plan.js
test plan = {"name": "VIS Test Plan", "spec version": "v3.0a", "build date": "240918", ...}
3.6.3.7 Report XML Content
The tools shall refer to the XML table below in populating the Test Case Filtering report content.
Within the table:
- [M] = Mandatory
- [C] = Conditional
- [O] = Optional
The Appendix F Report XML File provides more description of each column in the table.
Test Case Filtering Report
| Element/Node (1|2|3|4) |
Occurrence (Min..Max) | Description | Content ([Condition]: DataType | Parameter | Value) / Example (e.g.) |
|---|---|---|---|
| TestCaseFilteringReport | 1..1 | The Root element of the Test Report. Contains attributes:
|
Attributes ([Condition]: DataType | Parameter | Value):
E.g.: <TestCaseFilteringReport xsi:noNamespaceSchemaLocation=" TestCaseFilteringReportSchema1_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">…\</TestCaseFilteringReport> |
| _ ResultFileInfo | 1..1 | Container tag for result file information | - |
| _ _ DateTime | 1..1 | Timestamp of the result file | Text Content: [M]: String. E.g.: “2025-09-18T14:32:00Z” |
| _ _ ToolInfo | 1..1 | Container tag for tool information | - |
| _ _ _ ToolName | 1..1 | Identifies the test tool name | Text Content: [M]: String. E.g.: "ART" |
| _ _ _ ToolVersion | 1..1 | Identifies the test tool version | Text Content: [M]: String. E.g.: "1.0" |
| _ _ TestPlanInfo | 1..1 | Container tag for test plan information | - |
| _ _ _ PackageName | 1..1 | The Official test plan package file name as received from Visa | Text Content: [M]: String. E.g.: "VIS_Test_Plan_v3_0a_Build_240918.7z |
| _ _ _Name | 1..1 | Value of the “name” key of test_plan object as specified in [PackageName]/data/test_plan.js file | Text Content: [M]: String. E.g.: "VIS Test Plan" |
| _ _ _Version | 1..1 | Value of the “spec_version” key of test_plan object as specified in [PackageName]/data/test_plan.js file | Text Content: [M]: String. E.g.: "v3.0a" |
| _ _ _BuildDate | 1..1 | Value of the “build_date” key as specified in [PackageName]/data/test_plan.js file | Text Content: [M]: String. E.g.: "240918" |
| _ ProductICS | 1.1 | Container tag for product ICS | - |
| _ _ Field | 1.. var | Contains attributes:
|
Text Content: [M]: Boolean. E.g.: true, false |
| _ TestCaseApplicability | 1.1 | Container tag for test case applicability | - |
| _ _ TestCase | 1.. var | Contains attributes:
|
Text Content: |
3.6.4 Test Case Filtering Validation
As part of the usual Test Tool qualification, the Test Case Filtering Report content will be minimally validated as per follows:
-
The Test Case Filtering Report follows the xml schema provided with this document
-
The correctness of ICS answers
a. ICS answer content is complete as per the test plan
b. If an ICS answering schema is delivered together with the test plan, the rules for ICS answering is adhered and validated based on the schema e.g. [PackageName]\schema\ICS_VIS_v3.0a_Schema_v1.xsd
-
The correctness of Test case applicability
a. The test case IDs list is complete as per the test plan
b. The test case applicability is correct based on the ICS answers
3.7 Using the ICS Schema
An ICS Schema file specific to each Test Plan will be provided within the Test Plan package in the "schema" folder. This schema conforms to the W3C XML Schema Definition Language (XSD) and has a filename that begins with a prefix of "ICS".
Test Tool shall support the use of the ICS Schema to validate the ICS selection and to support the population of questions for ICS selection.
3.7.1 ICS Selection Validation
The schema may include the "assert" component within the "ICS" element. When present, it defines the validation rules for the ICS selections made by the user.
Test Tool Vendors are expected to incorporate these rules into their tools to enable automated validation of the user's ICS selection.
Refer to Digital Report for more information on the "assert" component.
3.7.2 ICS Mapping Information
The previous ICS Mapping Guide (.xlsx) which contains the ICS mapping information, questions, selection rules has been deprecated.
The equivalent information is now provided in the ICS Schema file:
- Selection Rules:
- described in "assert" component within "ICS" element (Refer to 3.7.1 ICS Selection Validation)
- ICS mapping information and questions:
- described in the "appinfo" section, which is nested inside the "annotation" component of the "ics-mapping" element.
3.7.2.1 "appinfo" Structure
The "appinfo" section contains the structured metadata mapping of each ICS questions to their corresponding ICS item(s), organized by categories. Test Tool Vendors shall use this information to provide the ICS questions to user and map the user's selections to the corresponding ICS item(s).
*NOTE: When there are more than one ICS item mapped to a question, refer to 3.3 Filtering Rules to ensure the correct processing of the ICS item to their question(s).
The structure of the "appinfo" section is as follows:
- A JSON structure is embedded within CDATA block
- The JSON defines a field "categories" (type: array of objects) which represent a grouping of questions. Each object contains:
- a field "name" (type: string) that defines the name of a category,
- a field "questions" (type: array of objects) that are specific to the category. Each object contains:
- a "text" field (type: string) describing the question,
- an "ics" field (type: array of string) that maps the question to one of more ICS items.
- The JSON defines a field "categories" (type: array of objects) which represent a grouping of questions. Each object contains:
Tabulated summary of the JSON struction within the CDATA block:
| Field | Type | Location | Description |
|---|---|---|---|
| categories | Array of objects | Root level of JSON | Represents a grouping of questions. Each category contains a name and a list of related questions |
| name | String | Inside each category object | The name of the category. |
| questions | Array of objects | Inside each category object | A list of questions related to the category. |
| text | String | Inside each question object | The text of the question. |
| ics | Array of strings | Inside each question object | A list of ICS items that map to the question. |
Example of the "ics-mapping" element:
<xs:element name="ics-mapping">
<xs:annotation>
<xs:documentation>
The content in xs:appinfo contains the structured metadata mapping of ICS item(s) to their corresponding questions. Questions are grouped by the category to which they belong.
</xs:documentation>
<xs:appinfo>
<![CDATA[
{
"categories": [
{
"name": "Additional Interfaces",
"questions": [
{
"text":"Is contact interface supported?",
"ics":["OPT_CONTACT_VSDC_FUNCTIONALITY_SUPPORTED"]
},
{
"text":"Does the device support Magnetic Stripe transactions?",
"ics":["OPT_MAGSTRIPE_SUPPORTED"]
}
]
}
{
"name": "VCPS Options",
"questions": [
{
"text": "The device supports online only?",
"ics": ["OPT_ONLINE_ONLY","OPT_ONLINE_CAPABLE"]
},
{
"text": "The device supports offline only?",
"ics": ["OPT_OFFLINE_ONLY","OPT_OFFLINE_CAPABLE"]
},
{
"text": "The device supports both online capable and offline capable?",
"ics": ["OPT_ONLINE_CAPABLE","OPT_OFFLINE_CAPABLE"]
}
]
}
]
}
]]>
</xs:appinfo>
</xs:annotation>
</xs:element>
4 Test Case Execution
Reader/Terminal vendors are not required to implement automation as described in Companion Guide specifications. The table below shows the contrast in test case execution processing when ran in Automated Mode and Regular mode. The Test Tools shall be able to support both of these modes.
Overview of Test Case Execution
| Automated Mode | Regular Mode |
|---|---|
| TT/RC: HTTP: Start of Transaction | User: Configures the Reader/Terminal and/or Host Simulator based on Transaction Configuration requirements |
| TT: Displays the test instructions | TT: Displays the test instructions |
| TT: Performs card emulation | TT: Performs card emulation |
| TT/RC: HTTP: End of Transaction | -- |
User: Visual Check (Conditional) |
User: Visual Check (Mandatory) |
| TT: Performs test case validation | TT: Performs test case validation |
| TT: Displays test verdict | TT: Displays test verdict |
Legend:
- TT – Test Tool
- RC – Reader Controller
- User – Test Tool User, indicates where human intervention is required
The VCPS Reader Test Plan when ran in Automated mode, minimizes human interaction (only when Visual Check is required). However when ran in Regular mode, human intervention is mandatory (Transaction Configuration and Visual Check is mandatory) all throughout the test plan run. While there are two modes of execution available, it is highly recommended to use the test automation Automated mode to minimize human errors, optimize testing strategy and significantly reduce testing times.
4.1 Test Execution Mode
The user shall be able to select the mode of test execution depending on product submission:
a) Automated mode
Automated mode is only applicable to products that is submitted with Reader Controller and Physical Reader complaint to the Companion Guide document.
b) Regular mode
When a product submitted does not support automation i.e. non-compliant to the Companion Guide document.
4.2 Test Groups
It is important to group run test cases in specific order to ease test execution and optimize completion time. This will help the product-under-test to re-use the same configuration for test cases within the same test group. Similarly, this will improve the work flow for the test execution since the tester may run the non-visual tests (estimated around 80% of the test plan) possibly (if the test tools use card probe technology for card emulation) in full automation.
The following steps illustrates the flow for creating the test group master list:
-
Use configuration mapping as test groups master list (config_mapping.xml)
-
Apply ICS test case filtering (as described in Section 3 Test Case Filtering)
-
Determine whether the functional test is functional full or functional regression
-
If functional regression is required, use regression_list.xml to eliminate test cases not required for regression run
-
Determine whether the test execution mode is Automated mode or Regular mode
-
If test execution mode is Automated mode, use visual_list.xml to group together:
a. Non-Visual test cases (test cases not requiring visual check)
b. Visual test cases (test cases requiring visual check)
4.3 Transaction Configuration
4.3.1 XML Information
Transaction Configuration is found in transaction_<test case>.xml enclosed within the <Configuration> element. These data are the test pre-requisites and expected reader-terminal configuration for running a test case transaction.
Note: Refer to Companion Guide for the details and full list of Transaction Configuration.
To facilitate proper configuration of TermSIM, the Test tools are required to send the full <Configuration> as per the test case transaction XML.
E.g.
Depending on the test execution mode selected, the usage differs:
a) Automated mode
In this mode, the XML content shall be digitally delivered via HTTP Start-of-Transaction message to the Reader Controller. Subsequently, the Reader Controller passes the information to the Physical Reader. Then, the physical reader automatically configures itself and starts the transaction without human intervention (amount entry is automated).
b) Regular mode
In this mode, the XML content equivalent is displayed by the Test Tool to enable the user to manually configure the physical reader/terminal and/or host simulator according to the test case requirement. After configuration, the user manually starts the transaction by entering the amount. Do note that the test tool is expected to translate the XML content into a comprehensible manner for the user to follow.
Note: If the reader/terminal supports Kernel 8 processing, Test Tool shall ensure that prior to testing, the reader/terminal is configured properly according to the requirements stated in Appendix E Kernel 8.
Sample content <Configuration> within transaction_<test case>.xml:
<Test>
<Configuration Test_ID="T_5_85_C01_01" Config_ID="config_1">
<General>
<Tag name="Transaction Currency Code" ID="5F2A">0840</Tag>
<Tag name="Transaction Currency Exponent" ID="5F36">02</Tag>
<Tag name="Transaction Type" ID="9C">01</Tag>
<Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000200</Tag>
<Tag name="Amount, Other (Numeric)" ID="9F03">000000000000</Tag>
<Tag name="Terminal Country Code" ID="9F1A">0840</Tag>
<Tag name="Terminal Floor Limit" ID="9F1B"/>
<Tag name="Merchant Name and Location" ID="9F4E"/>
<Tag name="Online-Only Reader Enabled" ID="ONLINE_ONLY_READER_ENABLED">False</Tag>
<Tag name="AUC, Manual Cash Check Enabled" ID="AUC_MANUAL_CASH_CHECK_ENABLED">False</Tag>
<Tag name="AUC, Cashback Check Enabled" ID="AUC_CASHBACK_CHECK_ENABLED">False</Tag>
<Tag name="IRWIN, Do Not Transmit" ID="IRWIN_DO_NOT_TRANSMIT"/>
<Tag name="TTQ - MSD Support" ID="TTQ_MSD_SUPPORT">False</Tag>
<Tag name="TTQ - qVSDC Support" ID="TTQ_QVSDC_SUPPORT">True</Tag>
<Tag name="TTQ - Offline Only Reader" ID="TTQ_OFFLINE_ONLY_READER">False</Tag>
<Tag name="TTQ - Online PIN Support" ID="TTQ_ONLINE_PIN_SUPPORT">False</Tag>
<Tag name="TTQ - Signature Support" ID="TTQ_SIGNATURE_SUPPORT">False</Tag>
<Tag name="TTQ - ODA For Online Authorization Support" ID="TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT">False</Tag>
<Tag name="TTQ - Mobile Functionality CDCVM Support" ID="TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT">True</Tag>
</General>
<Exception_File_Check Enabled="False"/>
<Pre-processing Enabled="False"/>
<DRL Enabled="False"/>
<Expected_Host_Response>
<Tag name="Authorization Response Code" ID="8A">00</Tag>
<Tag name="Issuer Authentication Data" ID="91">1234567803820000</Tag>
<Tag name="Issuer Script" ID="ISSUER_SCRIPT">71449F180412345678861304DA9F520E0000010000001234567890123456861104DA9F680C401000001234567890123456861304DA9F6B0E0000002000001234567890123456</Tag>
</Expected_Host_Response>
<Certification_Revocation_List/>
</Configuration>
</Test>
4.4 Test Instruction
4.4.1 XML Information
Test steps for each test case is available for Test Tools to display. This serves as a guide to the users on how to perform the test and what to validate for each step. The details can be found in transaction_<test case>.xml enclosed within <Test_Instruction> tag.
Sample content of <Test_Instruction> in transaction_<test case>.xml:
<Test>
<Test_Instruction>
<Step Description="Present a contactless card to the reader and
perform transaction until completion"/>
<Step Description="Re-present the contactless card for second tap (Online Approval)">
<Event>EVT_NOTIFY_OUTCOME_APPROVED</Event>
<Check>CHK_EXP_ACQ_DATA</Check>
<AcquirerData>
<DE_9F39>07</DE_9F39>
<DE_9F10>06011203A00000</DE_9F10>
<DE_9F1A>0840</DE_9F1A>
<DE_9A> Match actual value with APDU data </DE_9A>
<DE_9C>00</DE_9C>
<DE_9F26>Match actual value with APDU data</DE_9F26>
<DE_9F36>0001</DE_9F36>
<DE_9F37>Match actual value with APDU data</DE_9F37>
<DE_9F5B>14|1400000000</DE_9F5B>
<DE_82>2020</DE_82>
<DE_9F6E>20400000</DE_9F6E>
<DE_9F02>000000000200</DE_9F02>
<DE_5F2A>0840</DE_5F2A>
<DE_9F03>000000000000</DE_9F03>
<DE_9F7C/><DE_5F34>00</DE_5F34>
<DE_9F24/>
<DE_95>0000000000</DE_95>
<DE_57>4761739001010010D20122011234599999991F</DE_57>
<DE_TERMINAL_ENTRY_CAPABILITY>05|08</DE_TERMINAL_ENTRY_CAPABILITY>
</AcquirerData>
</Step>
</Test_Instruction>
</Test>
| XML Element/Attribute | Description | Requirement | Example Value |
|---|---|---|---|
| Test_Instruction | Container element for Test Steps | Mandatory | -- |
| Step | Container element for a single Test Step | Mandatory | -- |
| Description | Description of a Test Step | Mandatory | “Present a contactless card to the reader and perform transaction until completion” |
| Event | Name of an event that is expected to occur at a particular step. See full list and its description in Appendix B |
Conditional | EVT_NOTIFY_OUTCOME_APPROVED |
| Check | Name of the check that is required be performed by the user. See full list and its description in Appendix B |
Conditional | CHK_EXP_ACQ_DATA, CHK_APDU_LOG |
| AcquirerData | Container element that is only present when the Acquirer Data content needs to be validated by the user. Contains the sub elements DE_xxxx. | Conditional | -- |
| DE_xxxx | The Data element that needs to be verified by the user. ‘xxxx’ is a tag name and the value contains the matching rule:
See Appendix B Reader Status and Event for the sample content of expected Data Elements for each container. |
Conditional | 2000, Match actual value with APDU data, 05|07 |
Sample Test Instruction Display:
4.5 Card Emulation
4.5.1 Technology
Test Tools are required to do some form of card emulation for test plan execution. Technology examples are below but implementation is not limited to the usage of:
- Card Probe
- Physical Smart Card
4.5.2 XML Information
Data used for Card emulation is unique for every test case. The details can be found in transaction_<test case>.xml enclosed within <Transaction> tag.
Sample content of transaction_<test case>.xml:
<Test>
<Transaction>
<RESET>
<Protocol name="CONTACTLESS"/>
</RESET>
<APDU>
<Command name="SELECT" AID="325041592E5359532E4444463031"/>
<TerminalRequest>00A404000E325041592E5359532E444446303100 </TerminalRequest>
<CardResponse>6F32840E325041592E5359532E4444463031A520BF0C1D611B4F07
A000000003101050105649534120434F4E544143544C4553539000</CardResponse>
</APDU>
<APDU>
<Command name="SELECT" AID="A0000000031010"/>
<TerminalRequest>00A4040007A000000003101000</TerminalRequest>
<CardResponse>6F438407A0000000031010A53850105649534120434F4E544143544C
4553539F38189F66049F02069F03069F1A0295055F2A029A039C019F3704BF0C08
9F5A0510084008409000</CardResponse>
</APDU>
……
</Transaction>
</Test>
| XML Element/Attribute | Description | Requirement | Example Value |
|---|---|---|---|
| Transaction | Container element for Card Emulation | NA | -- |
| RESET | Container element to indicate RESET (powering on-off) expected by the card emulation. This is the state where Answer-To-Reset (ATR) is sent back by the card emulation. | NA | -- |
| Protocol | Indicates the type of interface protocol (contact, contactless) used for the subsequent APDU tags | NA | -- |
| APDU | Container element for each APDU command. May contain attribute "OPTIONAL" to indicate if the presence of the command is optional. |
ALL | -- |
| Command | Contains the attributes of a particular command to be used for emulation processing (such as matching rule, dynamic cryptograms, key information) | ALL | None |
| name | Descriptive name of the command or interface | ALL | “CONTACTLESS”, “SELECT”, “GPO” |
| TerminalRequest | Expected input APDU from the reader-terminal | ALL | 00A4040007A000000003101000 |
| CardResponse | Equivalent output APDU response from the Card when the TerminalRequest is matched. Note: Some commands will require dynamic update of some data elements within the CardResponse (i.e. SDAD). See REGENERATE_SDAD. |
ALL | 9000 |
| AID | Value of the AID to be matched with the incoming APDU command | SELECT | “A0000000031010” |
| REGENERATE_SDAD | Indicates the need to regenerate and subsequently replace the SDAD inside the GPO or READ RECORD command | GPO | “True”, “False” |
| PDOL_DATA | Informative JSON structure of static PDOL data when the GPO command TerminalRequest data in the XML is parsed Note: Due to dynamic matching rule GPO, LIVE TerminalRequest data may not match the values indicated. See MATCHING_RULE element. |
GPO | “{‘9F66’: ‘20004000’, ‘9F1A’: ‘0840’, ‘9A’: ‘170601’, ‘9C’: ‘00’, ‘5F2A’: ‘0840’, ‘9F37’: ‘UNPREDICTABLE_NUMBER’, ‘9F03’: ‘000000000000’, ‘9F02’: ‘000000000200’, ‘95’: ‘0000000000’}” Note: Zero length string when empty (i.e. “”) |
| MATCHING_RULE | JSON structure that describes the matching rule needed for Data Elements contained in the incoming command. The Data Element could include parameters (i.e. ‘P1’, ‘P2’) of the command header as well. MASK_DE: Key, Value pair denotes Key as the Data Element to match and Value as the bitwise matching rule ‘x’ – means value of the bit shall match ‘?’ – means any value is accepted for this bit ‘?*’ – means for all the bits of the data element, any value is accepted. Refer to Section 4.5.4.1 |
GPO, GAC, SPI | “{‘MASK_DE’: {‘9F66’: ‘xxx?xxxxxx? xxxxxxxxxxxxxxxxxxxxx’, ‘9F37’: ‘????????????????????????????????’}}” "{‘MASK_DE’: {‘P1’: ‘????????’, ‘9F37’: ‘????????????????????????????????’, ‘9F33’: ‘?*’}}” Note: Zero length string when empty (i.e. “”) |
| FDDA_INFO | JSON structure to aid in SDAD recalculation. Key, Value pairs:
|
GPO | “{‘REPLACE_SDAD_DATA_FORMAT’: None, ‘ICC_PRIVATE_KEY’: ‘RSA_ICC_TEST_KEY_1024_EXP03’, ‘SDAD_INPUT_TO_HASH’: {‘9F36’: ‘0001’, ‘9F02’: ‘000000000200’, ‘9F69’: ‘01A0D401BB0000’, ‘5F2A’: ‘0840’, ‘9F37’: ‘UNPREDICTABLE_NUMBER’}, ‘SDAD_IN_RECORD’: None}” Note: Zero length string when empty (i.e. “”) |
| OPTIONAL | An optional attribute in APDU element. The attribute indicates if the presence of the command is optional.
|
-- | "True" |
Note: Kernel 8 transactions could use additional elements/attributes not listed in the table. They are separately described in K8 Card Response Emulation.
4.5.3 Emulation Requirements
Minimum requirements for card emulation are as follows:
-
Card emulation shall follow the ISO/IEC 7816 for contact card emulation and ISO/IEC 14443 for contactless card emulation.
-
Card emulation shall be capable of logging ALL incoming and outgoing APDU commands exchange between the card and the reader-terminal, including Second Tap
-
If the <Transaction/> container is empty, this means the test does not expect a transaction to proceed. However, the card emulation shall still be activated but only responds to RESET and returns back the ATR. All APDUs shall return SW=6F02 (Proprietary response, command does not match expected).
-
At RESET, the card emulation shall clear up its transient variables and craft a standard ATR response
- Multiple RESETs are acceptable while emulation is still in the RESET state. That means multiple ATR response shall be returned to the Reader. At this state, when an APDU command comes in (e.g. SELECT), the emulation shall begin to follow the APDU sequence as stated in the XML.
-
Card emulation shall follow the sequence of APDU commands as listed inside the XML.
-
If the incoming command matches the APDU header (CLA, INS, P1, P2) of the next <TerminalRequest> command in the sequence, the card emulation shall reply with the equivalent <CardResponse>.
-
If the incoming command is a GPO command and SW=9000: If the REGENERATE_SDAD flag is “True”; the card emulation shall dynamically re-calculate the SDAD real-time using the keys referenced in the XML and the data elements provided by both the card and the reader-terminal during the APDU commands exchange (Note: This is Mandatory feature to be supported by the test tools)
-
ISSUER SCRIPT commands shall not affect any data or the state of card emulation (e.g. Card Block or Application Block shall not change the card state)
-
-
If the incoming command does not match the APDU header (CLA, INS, P1, P2) of the next <TerminalRequest> command in the sequence, the sequence is considered as not followed. The card emulation shall return SW=6F02 (Proprietary response, command does not match expected)
-
-
For all incoming commands received, the test tool shall perform content matching
-
If the <Transaction/> container is empty (see step 3), and any RESET or any APDU command is received from the reader-terminal, the test case shall be flagged as failed.
-
If the incoming APDU command content does not match (see matching rule in Section 4.5.4 Matching Rule), the test case shall be flagged as failed.
-
-
If a communication exist between the tool and card emulation (i.e. card probe or equivalent), receipt of HTTP End-of-Transaction Message marks the end of card emulation (see Appendix A Test Message). Timeout can also be used for ending the card emulation. If the Tool does not receive HTTP End-of-Transaction Message within this timeframe then the emulation shall end. Recommended timeout is 30 seconds (countdown starts from the first ATR). The timeout setting shall be configurable from the tool.
4.5.4 Matching Rule
ALL incoming commands from Reader/Terminal shall match EXACTLY the values as stated in <TerminalRequest> element under each <APDU> container. This matching shall be performed for all incoming APDU commands with the exception of command(s) that carries a non-empty ‘MATCHING_RULE’ attribute.
<APDU>
<Command AID="325041592E5359532E4444463031" name="SELECT"/>
<TerminalRequest>00A404000E325041592E5359532E444446303100</TerminalRequest>
<CardResponse>6F32840E325041592E5359532E4444463031A520BF0C1D611B4F07A000000003101050105649534120434F4E544143544C4553539000</CardResponse>
</APDU>
Example of matching rule in GPO command in XML:
<APDU>
<Command name="GPO" REGENERATE_SDAD="True" PDOL_DATA="{'9F66': '20004000', '9F1A': '0840', '9A': 'TRANSACTION_DATE', '9C': '00', '5F2A': '0840', '9F37': 'UNPREDICTABLE_NUMBER', '9F03': '000000000000', '9F02': '000000000200', '95': '0000000000'}" MATCHING_RULE="{'MASK_DE': {'9F66': 'xxx?xxxxxx?xxxxxxxxxxxxxxxxxxxxx', '9F37': '????????????????????????????????', '9A': '????????????????????????'}}" FDDA_INFO="{'REPLACE_SDAD_DATA_FORMAT': None, 'ICC_PRIVATE_KEY': 'RSA_ICC_TEST_KEY_1024_EXP03', 'SDAD_INPUT_TO_HASH': {'9F36': '0001', '9F02': '000000000200', '9F69': '01A0D401BB0000', '5F2A': '0840', '9F37': 'UNPREDICTABLE_NUMBER'}, 'SDAD_IN_RECORD': None}"/>
<TerminalRequest>80A8000023832120004000000000000200000000000000084000000000000840170601001234567800</TerminalRequest>
<CardResponse> 7781C657134761739001010010D20122011234599999991F9F2701409F2608182E70627E50CC369F360200019F6C0200009F100706011203900000820220209404100203009F4B8180A2E528F31C3D5C83346A39682ADA7B28F8005C43EABF1E5FF8E57563FACA2D2F831E7356AC51A1E239A8BA6C5757B83ABC0EF1FC815DDCCFFB205580D527C24972A79A372711FC0817EDA8D6405D3B575A8CB360277230FA06A2AD5AC3EFC76E20926C0E3DDFF4D3141922E3D4E6FBAEC77BFBDE0B1EEB0379FE4D8A72A252419000</CardResponse>
Note: Not all commands will have the MATCHING_RULE attribute.
MATCHING_RULE specifies the rule(s) needed to match the request command. This contains a JSON structure with MASK_DE root key and a list of key, value pairs. The list concerns the Data Elements that need to be bitwise masked when doing a comparison. When a bit is masked, any bit value is accepted, 0b or 1b. In the above GPO command XML example, three data elements are masked for matching. Table below illustrates how the data elements are masked.
| Data Element | Byte1 | Byte2 | Byte3 | Byte4 | … | Remarks |
|---|---|---|---|---|---|---|
| 9F66 Terminal Transaction Qualifiers (TTQ) |
xxx?xxxx | xx?xxxxx | xxxxxxxx | xxxxxxxx | -- | -- |
| 9F37 Unpredictable Number (Reader/Terminal) |
???????? | ???????? | ???????? | ???????? | -- | Unpredictable Number all 4 bytes shall be masked. Meaning any 4-byte value is acceptable. Static example: 12345678 |
| 9A Transaction Date |
???????? | ???????? | ???????? | -- | -- | Transaction Date is dependent on execution date. |
4.5.4.1 '?*' Matching Rule
A data element may also be represented with a ‘?*’ masking rule.
This means that all bits (starting from the first bit) of the data element are masked and any value (0 or 1) per bit received is acceptable.
The length of the data received from the Reader/Terminal shall be checked against the expected length (requested dol length/simulated data length) in the XML regardless if all bits are masked. A mismatch in the data length shall constitute to a Fail.
Using the same GPO example above, the masking rule for Transaction Date (Tag 9A) may be represented by ‘?*’ instead of ‘????????????????????????’, i.e. “{‘9A’: ‘?*’}”. The length of Transaction Date received shall match the length of the requested dol/simulated data in theXML.
Note: The masking rule may be interchangeably used based on testing needs and no fixed rule is tied to a data element.
4.5.5 Dynamic Cryptographic Calculations
As some data are generated on-the-go or random by nature, the test tool must perform dynamic calculation and/or validation of TDES/RSA cryptographic operations as required based on the extracted values generated within a transaction (e.g. ATC values, CVR values or ICC Dynamic Number).
These dynamic cryptogram computations is only used in CONTACTLESS interface. They are identified as below and shall be done throughout the execution of all test cases.
Sample GPO command in XML:
<APDU>
<Command name="GPO" REGENERATE_SDAD="True" PDOL_DATA="{'9F66': '20004000', '9F1A': '0840', '9A': 'TRANSACTION_DATE', '9C': '00', '5F2A': '0840', '9F37': 'UNPREDICTABLE_NUMBER', '9F03': '000000000000', '9F02': '000000000200', '95': '0000000000'}" MATCHING_RULE="{'MASK_DE': {'9F66': 'xxx?xxxxxx?xxxxxxxxxxxxxxxxxxxxx', '9F37': '????????????????????????????????', '9A': '????????????????????????'}}" FDDA_INFO="{'REPLACE_SDAD_DATA_FORMAT': None, 'ICC_PRIVATE_KEY': 'RSA_ICC_TEST_KEY_1024_EXP03', 'SDAD_INPUT_TO_HASH': {'9F36': '0001', '9F02': '000000000200', '9F69': '01A0D401BB0000', '5F2A': '0840', '9F37': 'UNPREDICTABLE_NUMBER'}, 'SDAD_IN_RECORD': None}" />
<TerminalRequest>80A8000023832120004000000000000200000000000000084000000000000840170601001234567800</TerminalRequest>
<CardResponse> 7781C657134761739001010010D20122011234599999991F9F2701409F2608182E70627E50CC369F360200019F6C0200009F100706011203900000820220209404100203009F4B8180A2E528F31C3D5C83346A39682ADA7B28F8005C43EABF1E5FF8E57563FACA2D2F831E7356AC51A1E239A8BA6C5757B83ABC0EF1FC815DDCCFFB205580D527C24972A79A372711FC0817EDA8D6405D3B575A8CB360277230FA06A2AD5AC3EFC76E20926C0E3DDFF4D3141922E3D4E6FBAEC77BFBDE0B1EEB0379FE4D8A72A252419000</CardResponse>
</APDU>
When REGENERATE_SDAD is set to “True”, refer to FDDA_INFO (JSON structure key, value pairs) to generate a Signed Dynamic Application Data (SDAD). SDAD value is returned in either GPO or READ_RECORD data. See Table 4-2 for the details of FDDA_INFO. The Test Tool shall also ensure that the Reader-Terminal Unpredictable Number (tag ‘9F37’) received is uniquely random.
4.5.6 K8 Card Response Emulation
The VCPS Reader Application Selection Test Plan covers generic Kernel 8 transactions and Tool shall ensure that prior to testing, the reader, if supporting Kernel 8 processing, is configured properly according to the requirements stated in Appendix E Kernel 8.
A K8 transaction can be identified when the attribute “CARD_KEY_DATA_INFO” is present and not empty in the GPO <Command> element.
When processing a K8 transaction, the GPO, Encrypted Read Record and the GENERATE AC response from the XML shall be dynamically adjusted using the corresponding command data received from the reader-Terminal, before returning the adjusted response to the reader-Terminal.
Details of adjusting the card response are described in the subsections.
Note: Any cryptographic computations described in this section may be referred to the VCPS 3.0 specification.
4.5.6.1 GPO Response: Derive SKC, SKI and Recompute Card Key Data
<APDU>
<Command name="GPO" REGENERATE_SDAD="False" FDDA_INFO="" CARD_KEY_DATA_INFO="{'BLINDING_FACTOR': 'D85C950AEE7A6089BD87E7D5171072E902F55ACEB0F11496957153E9E80D0B6F', 'ICC_ECC_KEY': 'ECC_ICC_P256_01'}" PDOL_DATA="{'9F66': '00000000', '9F02': '000000000200', '9F03': '000000000000', '9F1A': '0840', '95': ' TERMINAL_VERIFICATION_RESULTS_TVR', '5F2A': '0840', '9A': 'TRANSACTION_DATE', '9C': '00', '9F37': 'UNPREDICTABLE_NUMBER', '9F2B': 'KERNEL_QUALIFIER', '9E': 'KERNEL_KEY_DATA'}" MATCHING_RULE="{'MASK_DE': {'9F37': '????????????????????????????????', '9A': '????????????????????????', '9F2B': '?*', '9E': '?*', ‘95’: ‘?*’}}"/>
<TerminalRequest> 80A800006B83690000000000000000020000000000000008400000000080084017060100123456780280001011FF0000548C4AD08AF7F339C9CDCDEE1903D04DE2AD3F920A4786E622D6C91CBD4B6DAE6A73156B521093E36B3964D95D428B1B1ADAE02EDA6CE26C684A7E27B46CED2200</TerminalRequest>
<CardResponse> 776B820200249404180101008C1B9F1D089F33039F02069F03069F1A0295055F2A029A039C019F37049F8103405151F30C4C1C6B242A5C78871078C95CC3DC2207ED1E415411A4D4B62E4E57FAA664389E637D08E583F5BE269B815517BA26883DA1E6341057A08F1CBCE13A2D9000</CardResponse>
</APDU>
In a K8 GPO Response, Tool shall perform the Blinded Diffie-Hellman (BDH) protocol to compute the Session Key for Integrity (SKI) and the Session Key for Confidentiality (SKC) to be used for the transaction and repopulate the Card Key Data (Tag 9F8103) in the response. The following data objects shall be used to achieve this:
- Kernel Key Data (Tag ‘9E’) returned from the Reader-Terminal
- Blinding Factor in the attribute “CARD_KEY_DATA_INFO” of the
element - ICC ECC Key in the attribute “CARD_KEY_DATA_INFO” of the
element - The value is a label which points to the ICC ECC keys information in icc_keys.xml. Refer to Appendix C.1 ICC Private Keys for details.
The Card Key Data (Tag 9F8103) value within the GPO response in the XML shall be replaced by the recalculated value.
The derived SKC, SKI and the GPO command data field received from the Reader-Terminal shall be saved for later use in the transaction.
4.5.6.2 READ RECORD Response: Recompute Encrypted Response
<APDU>
<Command name="READ_RECORDS" REC="01" SFI="03" RECORD_BODY_TO_BE_ENCRYPTED="5F24033012315A0847617390010100109F810D0230009F810A069F2C848C9F389F6E04207000009F8107010957134761739001010010D30122011234599999991F"/>
<TerminalRequest> 00B2011C00</TerminalRequest>
<CardResponse> DA417AB40CFA79C7F880D49090CCB49891180400CF7F5D08AEA8D40D6727E179995538F5F4D0F2ED184896F4A185F22700DF931812EE8DBBD4D04AD5D029935B4CEDDE9000</CardResponse>
</APDU>
In a READ RECORD response, when the attribute “RECORD_BODY_TO_BE_ENCRYPTED” is present within the
- Derived SKC from GPO in Section 4.5.6.1 as the session key
- Plain Record body which is indicated by the value in attribute ‘RECORD_BODY_TO_BE_ENCRYPTED’ as the encryption input message
The value field of the READ RECORD response in the XML shall be replaced by the recomputed encrypted response. Note that for an encrypted read record response the Template Tag would be “DA” instead of “70”.
4.5.6.3 GENERATE AC Response: Recompute IAD MAC, EDA MAC
<APDU>
<Command name="FIRST_GENERATE_AC" REGENERATE_EDA_MAC="True" IAD_MAC_INFO="{'GENAC_RESPONSE_WO_AC_EDAMAC': 9F101106011203A00000091000000000000000009F2701809F360200019F810201009F81040580000000819F8108021F00, 'AIP': '0024', 'P_EXTENDED_SDA_TAG_LIST_RELATED_DATA': 9F2C070200FFFF0000008407A00000000310108C1B9F1D089F33039F02069F03069F1A0295055F2A029A039C019F37049F381D9F66049F02069F03069F1A0295055F2A029A039C019F37049F2B089E40}" CDOL_DATA="{'9F1D': 'TERMINAL_RISK_MANAGEMENT_DATA', '9F33': 'TERMINAL_CAPABILITIES', '9F02': '000000000200', '9F03': '000000000000', '9F1A': '0840', '95': 'TERMINAL_VERIFICATION_RESULTS_TVR', '5F2A': '0840', '9A': 'TRANSACTION_DATE', '9C': '00', '9F37': 'UNPREDICTABLE_NUMBER'}" MATCHING_RULE="{'MASK_DE': {'9F37': '?*', '9A': '?*', '9F1D': '?*', '9F33': '?*', '95': '?*'}}}"/>
<TerminalRequest>80AE8000280000000000000000000000000000000200000000000000084080000000810840170601001234567800</TerminalRequest>
<CardResponse> 77489F101106011203A00000091000000000000000009F2701809F360200019F810201009F81040580000000819F8108021F009F2608A5737C688BC23A779F8105086C32287F26311CE09000</CardResponse>
</APDU>
In the GENERATE AC response, the presence of attribute “REGENERATE_EDA_MAC” with the value = “True” within the <Command> element, signifies the need to recompute the EDA MAC in the XML before sending to the Reader-Terminal. Prior to computing the EDA MAC, the IAD MAC which is a transient data in the transaction has to be computed. The computed IAD MAC is used to calculate the EDA MAC. Tool shall use the following data objects to compute IAD MAC:
- PDOL values which was the saved data field excluding template tag ‘83’ and length byte from the GPO command returned by Reader-Terminal
- CDOL1 related data from the GENERATE AC command data field returned by the Reader-Terminal
- GENERATE AC response data field without Tag ‘77’, length, AC & EDAMAC from the “GENAC_RESPONSE_WO_AC_EDAMAC” of attribute “IAD_MAC_INFO” within the <Command> element in the XML
- AIP value of card from the “AIP” of attribute “IAD_MAC_INFO” within the <Command> element in the XML
- P_Extended_SDA_Tag_List_Related_Data from the “P_EXTENDED_SDA_TAG_LIST_RELATED_DATA” of attribute “IAD_MAC_INFO” within the <Command> element in the XML
Note: IAD MAC does not involve any Exchange Relay Resistance Data (ERRD) data as ERRD command-response is not used in the reader test plan.
Upon deriving the IAD MAC, Tool shall use the value to compute the EDA MAC. It is not required to recompute the Application Cryptogram, AC (Tag ‘9F26’); Tool shall use the AC value provided in the XML.
The EDA MAC value in the XML shall be replaced by the computed value and sent to the Reader-Terminal.
4.6 Test Validation
For each test case, Test Tool shall employ validation of the following:
- Transaction Outcome – Confirmation of transaction outcome details (applies only for Automated mode)
- APDU – Validation of incoming command from Reader/Terminal (mandatory for both Automated mode and Regular mode)
- Visual Check – Confirmation of events / other extra checks (conditional for Automated mode, mandatory for Regular mode)
- Additional Output – Confirmation of additional transaction output details (applies only for VCTKS Test Plan automated mode)
4.6.1 Transaction Outcome
In Automated mode, HTTP End-of-Transaction message contains XML Data that shall be matched by following the matching rules with the <Transaction_Details> element present in the transaction_<test case>.xml.
Sample XML content
<Transaction_Details>
<Test_ID>T_0001</Test_ID>
<Transaction_Outcome MATCHING_RULE=”xxxx???x”>20</Transaction_Outcome>
<AcquirerData/>
<IRWINData/>
</Transaction_Details>
Sample HTTP End-of-Transaction message content:
POST / HTTP/1.1
Message: ETXN
Host: localhost:8080
Connection: keep-alive
Content-Length: 140
Content-Type: text/plain
<Transaction_Details><Test_ID>T_0001</Test_ID><Transaction_Outcome>20</Transaction_Outcome><AcquirerData/><IRWINData/></Transaction_Details>
Matching Rules:
The <Transaction_Details> stated in transaction_<test case>.xml shall be the reference content in checking the data within the ETXN Message Body.
If any of the following requirement is not met, the test case shall be flagged as failed.
- Message body shall have no XML Format error
- <Test_ID>, <Transaction_Outcome>, <AcquirerData> and <IRWINData> elements shall be present within <Transaction_Details> container element
- <Test_ID> value shall be an exact match with reference content
- <Transaction_Outcome> value shall match the reference content:
- If the reference content value has a “|” (pipe) this means that multiple values are acceptable to be matched. The values acceptable are separated by “|” (pipe(s)).
- MATCHING_RULE attribute indicates the masking rule for 1-byte transaction outcome value (e.g. “xxxx???x” means that bits 4-2 shall be masked when performing matching). MATCHING_RULE shall be applicable for all values in the reference content whether single or multiple values are specified.
- If the reference content value has a “|” (pipe) this means that multiple values are acceptable to be matched. The values acceptable are separated by “|” (pipe(s)).
- If <AcquirerData> container is not empty in reference content, the elements content shall be matched using the DE Comparison Technique below.
Else if thecontainer is empty in reference content, and data within the received <AcquirerData> shall be ignored. - If <IRWINData> container is not empty in reference content, the elements content shall be matched using the DE Comparison Technique below.
Else if the <IRWINData> container is empty in reference content, and data within the received <IRWINData> shall be ignored. - When validating VCTKS Test Plan, <Additional_Output> must be present within the <Transaction_Details> container element.
The value shall match the reference content from the xml:
- MATCHING_RULE attribute indicates the masking rule for 1-byte additional output value (e.g. “???xxxxx” means that bits 8-6 shall be masked when performing matching).
DE Comparison Technique
If any of the following requirement is not met, the test case shall be flagged as failed.
- All DE element tags from reference content shall be present and can be in any order
a. Missing DE element tags shall be deemed as test case failure
b. Extra DE element tags present but not in reference content is allowed but will not be compared and shall not be deemed as test case failure - The value of the DE shall match the reference content:
- If the reference content value has a “|” (pipe) this means that multiple values are acceptable to be matched. The values acceptable are separated by “|” (pipe(s)).
- If the reference content value states “Match actual value with APDU data”, the tool shall retrieve the same Date Element content from the card emulation APDU exchange and perform a real-time match.
- Otherwise, the values shall be an exact match.
Note: In Regular mode, the Transaction Outcome (& Additional Output for VCTKS Test Plan) details are checked by using Visual Check prompts (see Section 4.6.3 Visual Check).
| XML Element/Attribute | Description | Requirement | Example Value |
|---|---|---|---|
| Transaction_Outcome | Element that contains the value to be matched with HTTP End-of-Transaction message. Note: If the value has a pipe ‘|’ then multiple values are acceptable. E.g. if the value is E0|F0 then either E0 or F0 value is acceptable. |
Mandatory | 04, 06, 10, 20, 30, E0, F0 |
| Description | Description of the transaction outcome | Mandatory | “Offline Approval” |
| Value (left nibble) | Description | Event |
|---|---|---|
| '0' | Offline Approval | EVT_NOTIFY_OUTCOME_APPROVED |
| '1' | Offline Decline | EVT_NOTIFY_OUTCOME_DECLINED |
| '2' | Online Approval | EVT_NOTIFY_OUTCOME_APPROVED |
| '3' | Online Decline | EVT_NOTIFY_OUTCOME_DECLINED |
| 'E' | Switch Interface | EVT_NOTIFY_SWITCH_INTERFACE |
| 'F' | Terminate | EVT_NOTIFY_TERMINATE |
| 'E'|'F' | Switch Interface or Terminate. | EVT_NOTIFY_SWITCH_OR_TERMINATE |
| '1'|'2'|'3' | Either Offline Decline, Online Approved or Online Declined is acceptable | EVT_NOTIFY_OUTCOME_DECLINED_OR_GO_ONLINE |
| '0'|'1'|'2'|'3' | Either Offline Approved, Offline Decline, Online Approved or Online Declined is acceptable | EVT_NOTIFY_ANY_COMPLETION_OUTCOME |
| '1'|'3'|'F' | Either Offline Decline, Online Declined or Terminate is acceptable | EVT_NOTIFY_OUTCOME_DECLINED_OR_TERMINATE |
| '0'|'1'|'2'|'3'|'F' | Either Offline Approved, Offline Decline, Online Approved, Online Declined or Terminate is acceptable | EVT_NOTIFY_ANY_COMPLETION_OUTCOME_OR_TERMINATE |
| XML Element/Attribute | Description | Requirement | Example Value |
|---|---|---|---|
| Additional_Output | Element that contains the value to be matched with HTTP End-of-Transaction message. Note: This is applicable only for VCTKS Test Plan |
Mandatory | 00, 80, 20, A0 |
| Description | Description of the Additional Output | Mandatory | “Online Required by Reader Indicator” |
| Bit Value | Description | Event |
|---|---|---|
| bit 8 = 0 | Online Required by Reader Indicator Not Set | EVT_ONLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_0b |
| bit 8 = 1 | Online Required by Reader Indicator Set | EVT_ONLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_1b |
| bit 7 = 0 | Decline Required by Reader Indicator Not Set | EVT_DECLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_0b |
| bit 7 = 1 | Decline Required by Reader Indicator Set | EVT_DECLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_1b |
| bit 6 = 0 | Application PAN Not on Terminal Exception File | EVT_APPLICATION_PAN_NOT_ON_TERMINAL_EXCEPTION_FILE |
| bit 6 = 1 | Application PAN on Terminal Exception File | EVT_APPLICATION_PAN_ON_TERMINAL_EXCEPTION_FILE |
| bits 5-1 = 0 | Reserved for future use | -- |
4.6.2 APDU
Using the logs gathered from Section 4.5 Card Emulation, the following rules apply for APDU validation:
- If any of the Status Word is equal to 6F02, the test shall be flagged as failed.
- Any occurrence of ATR or APDU command in the logs when the <Transaction/> tag is empty shall be flagged as failed. This means that the Reader powered-on the interface when it was not expected to.
- If the APDU sequence does not match the APDU sequence in transaction_<test case>.xml within <Transaction>, the test shall be flagged as failed.
The following exceptions shall be considered before evaluating to a failure:-
multiple ATR within the same RESET state is acceptable. E.g. if the logs sequence is ATR, ATR, ATR, Select, GPO and the XML contains RESET, Select, GPO this is acceptable and shall not be flagged as failed.
-
<APDU> has an attribute "OPTIONAL" with a value of "True", e.g.
<APDU OPTIONAL="True">.
This attribute provides allowance for different implementation behaviour in specific scenarios. The presence of the attribute with a value "True" indicates that the command is optional; Test shall not fail if the command within this APDU was not received.
Nonetheless, if a command was received in correspondence to the APDU, Tool shall validate the command as per usual and any mismatch shall result in a fail.
Note: Where applicable, the occurence of an optional APDU happens in the last command(s) in the sequence. The first onset of an optional APDU in the transaction will be accompanied by subsequent optional APDU command(s).
Example of an optional APDU command:<Transaction> ... <APDU> <Command name="GPO"/> ... </APDU> <APDU> <Command name="READ_RECORDS"/> ... </APDU> <APDU OPTIONAL="True"> <Command name="READ_RECORDS"/> ... </APDU> </Transaction>
-
- All APDU Commands received shall be fully matched according to Section 4.5.4 Matching Rule.
4.6.3 Visual Check
Visual Check requirement differs when test execution is in Automated mode and in Regular mode.
4.6.3.1 List of Automated Mode
In Automated mode, not all test case requires visual check. The test tool shall refer to another XML file – visual_list.xml. This file contains the list of test cases that requires visual inspection and/or additional checks (see full list in Appendix B). When this test case is run, additional message prompt is required for the Test Tool to confirm validation with the user.
To save execution time, when a test case does not exist in visual_list.xml, the test tool shall not prompt for extra validation with the user.
Sample content of visual_list.xml:
<Visual_Checklist>
<TestCase Test_ID="T_5_85_C01_01" />
<TestCase Test_ID="T_5_24_C01_01" />
<TestCase Test_ID="T_5_80_C96_01" />
<TestCase Test_ID="T_5_83_C01_01" />
</Visual_Checklist>
| XML Element/Attribute | Description | Example Value |
|---|---|---|
| Visual_Checklist | Root element | -- |
| TestCase | Represents a test case that requires visual check. Multiple of this element may exist under <Visual_Checklist>. This element does not have a value and is always a closed tag <TestCase/> |
None |
| Test_ID | Attribute of TestCase that describes the equivalent test case ID | “T_5_85_C01_01” |
4.6.3.2 List for Regular Mode
In Regular mode, ALL test cases require visual check.
4.6.3.3 Validation of Visual Checks
The test tools shall use the Test Instructions (see Section 4.4) to determine the events and checks required for each test case. In this mode, ALL Events and additional checks listed in the transaction_<test case>.xml within <Test_Instruction> are required to be confirmed by the Test Tool to the user.
Once the test tool determines the list of events and/or checks required to be validated by a test case, the test tool shall prompt the user for confirmation(s). If the user did not confirm occurrence of the event or fails the validation checks, the test case shall be flagged as failed.
Example Event UI prompt:
Example Validation Check UI prompt:
5 Manual Test Plan
This section discusses the unique requirements for execution of Manual Test Plan. The Manual Test Plan main objective is to run test cases that are complex to be run within the automation architecture.
The contents and formats of these two test plans are the same except for the following topics discussed in the next sections.
5.1 No Test Message
The Manual Test Plan does not support Test Messages therefore; the following activities are manually driven:
-
Transaction Configuration as described in Section 4.2 Test Groups.
The transaction_<test case>.xml <Configuration> data element contains the attributes Test_ID and Config_ID and does not contain any sub elements. The Test Tool shall then use Config_ID attribute and refer to the equivalent config_<running number>.xml file referenced and display instructions for manual configuration. -
Transaction Outcome validation as described in Section 4.6.1 Transaction Outcome.
<Transaction_Outcome>will not be present in transaction_<test case>.xml
5.2 Card Emulation
Manual Test Plan also requires Card Emulation but the card emulation may use multiple cards and/or multiple interface.
In this context, a new data element <Card> is present inside transaction_<test case>.xml. Multiples of <Card> element may exist depending on the test requirement.
5.2.1 XML Information
Data used for Card emulation is unique for every test case. The details can be found in transaction_<test case>.xml enclosed within <Card> tag.
Sample content of <Card> within transaction_<test case>.xml:
<Test>
<Card name="Card_A" type="Contactless Interface Supported">
<RESET>
<Protocol name="CONTACTLESS"/>
</RESET>
<APDU>
<Command name="SELECT" AID="325041592E5359532E4444463031"/>
<TerminalRequest>00A404000E325041592E5359532E444446303100 </TerminalRequest>
<CardResponse>6F32840E325041592E5359532E4444463031A520BF0C1D611B4F07
A000000003101050105649534120434F4E544143544C4553539000</CardResponse>
</APDU>
<APDU>
<Command name="SELECT" AID="A0000000031010"/>
<TerminalRequest>00A4040007A000000003101000</TerminalRequest>
<CardResponse>6F438407A0000000031010A53850105649534120434F4E544143544C
4553539F38189F66049F02069F03069F1A0295055F2A029A039C019F3704BF0C08
9F5A0510084008409000</CardResponse>
</APDU>
……
</Card>
</Test>
| XML Element/Attribute | Description | Command Applicability | Example Value |
|---|---|---|---|
| Card | Container element for Card Emulation | NA | -- |
| name | Descriptive name of the card, command or interface Note: Card name matches the name as mentioned in Test Instruction (Section 4.3 Transaction Configuration). |
ALL | “Card_A”, “CONTACTLESS”, “SELECT”, “GPO” |
| type | Descriptive type of the card emulation | NA | “Contactless Interface Supported” |
| RESET | Container element to indicate RESET. For contact and contactless interface, this is the powering on-off expected by the card emulation. This is the state where Answer-To-Reset (ATR) is sent back by the card emulation. For Magstripe interface, this is the swipe action expected by the card emulation. |
NA | -- |
| Protocol | Indicates the type of interface protocol (contact, contactless, magstripe) used for the subsequent tags. | NA | -- |
| TRACK2_EQ_DATA | Track 2 according to ISO/IEC 7813, excluding start sentinel, end sentinel, and Longitudinal Redundancy Check (LRC); Note: Test tool shall emulate and encode the actual Track2 data. |
NA | “4761739001010010D20122011234599999991F” |
| APDU | Container element for each APDU command | ALL | -- |
| Command | Contains the attributes of a particular command to be used for emulation processing | ALL | None |
| TerminalRequest | Expected input APDU from the reader-terminal Note: For Manual test plan, GPO request command shall always accept any data within PDOL data. Other commands shall be an exact match. |
ALL | 00A4040007A000000003101000 |
| CardResponse | Equivalent output APDU response from the Card when the TerminalRequest is matched. A MUTE (No card response) emulation is required when this element contains an empty string Note: For Manual test plan, GPO response command shall always require dynamic update of SDAD in card response. |
ALL | 9000 |
| AID | Value of the AID to be matched with the incoming APDU command | SELECT | “A0000000031010” |
| SFI | Short File Identifier information | READ_RECORDS | “01” |
| REC | Record number information | READ_RECORDS | “01” |
5.2.2 Emulation Requirements
Similarly, emulation requirements as stated in Section 4.5.3 is applicable. Except for GPO commands (where GPO request command shall always accept any data within PDOL data).
Additional Requirements:
Magstripe Interface
- Track 2 Equivalent Data is provided as an attribute in <Protocol> element. Prior to encoding to Magstripe, the Test Tool shall include the start sentinel, end sentinel, and Longitudinal Redundancy Check (LRC) according to ISO/IEC 7813.
Contact Interface
- Both PSE selection method and List of AIDs selection method shall be supported by the card emulation. The card emulation shall manage to handle both of these methods regardless of the APDU sequence.
- In case where the AID does not (partial or full) match any of the SELECT command in the script, the tool shall return '6A82' (File not found).
- APDU sequence may not be followed strictly due to the nature of PSE selection method and AID selection method, which is both acceptable reader-terminal request for contact interface.
- FIRST_GENERATE_AC shall accept any value within the CDOL data.
- When SECOND_GENERATE_AC is requested and is not present in the XML, FIRST_GENERATE_AC response shall be re-used.
- FIRST_GENERATE_AC and SECOND_GENERATE_AC CID response shall adhere to the following rules:
-
Note: In VCPS test plan, only the items in bold are relevant.GAC P1 Request CID Defined in Test Plan CID to be Sent in Response TC TC TC TC ARQC ARQC TC AAC AAC ARQC TC ARQC ARQC ARQC ARQC ARQC AAC AAC AAC Not relevant AAC
Contactless Interface
- GPO command shall always accept any data within PDOL data.
5.3 Test Validation
Manual Test Plan only requires the test tool to validate Visual Checks as described in Section 4.6.3 Visual Check. Test tool by default shall use the Regular mode execution strategy to gather the list of events and additional checks as described in Section 4.6.3.2.
Note: There is no need to validate HTTP Transaction Outcome and APDU command logs for Manual Test Plan as described in Section 4.6.1 Transaction Outcome and Section 4.6.2 APDU.
6 VRTPKS Test Plan (Tap-to-Phone)
The VRTPKS Test Plan is using exactly the same format as the VCPS Reader Test Plan.
Along with this, the same rules and requirements apply with regards to Tool development and test automation.
7 VTTCD Test Plan (Tap-to-Consumer-Device)
The VTTCD Test Plan is using exactly the same format as the VCPS Reader Test Plan.
Along with this, the same rules and requirements apply with regards to Tool development and test automation.
8 VCTKS Test Plan (Visa Contactless Transit Kernel)
The VCTKS Test Plan is using the same format as the VCPS Reader Test Plan, with the following exception:
- Additional Output – Support and validation of additional transaction output details of the <Additional_Output> element (applies only for Automated mode).
In addition to the regular rules and requirements, new requirements are mandated to support the validation of the <Additional_Output>. Refer to Chapter 4.6 for details.
Appendix A Test Message
This section defines the flow, protocol, expectations and message handling between the Reader Controller (herein referred to as “client”) and the Test Tool (herein referred to as “server”) during the Test Message exchange.
Test Message utilizes the HTTP Protocol that is a TCP/IP based communication protocol. Hence, requires the server application to listen to an open TCP/IP socket (IP Address and Port) and the client application to send/receive HTTP Messages over the open socket. This architecture is synchronous and is applicable only for one-to-one communication with server and client (cannot be one-to-many).
Note: The IP Address and Port shall not be static and shall be made configurable by the client and server applications.
A.1 Overview
A.2 HTTP Message
Throughout the test messaging, below structure of HTTP Request and Response message (as defined in RFC 7230 and RFC 7231) are used. Below tables are for reference only. The parameters and values shown in these tables are recommended but shall not be mandated by the server or client applications.
HTTP – Request message
| Entity | Description |
|---|---|
| Request Line | request-method-name request-URI HTTP-version GET / HTTP/1.1 POST / HTTP/1.1 TRACE / HTTP/1.1 |
| Request Headers | request-header-name: request-header-value1, request-header-value2, ... Message: [Name of message] Host: [IP Address]:[Port] Connection: keep-alive If Request message body exists: Content-Type: text/plain |
| - | BLANK LINE |
| Request Message Body | XML Data (Conditional) |
HTTP – Response message
| Entity | Description |
|---|---|
| Status Line | HTTP-version status-code reason-phrase HTTP/1.1 200 OK (Other status-codes to be defined) |
| Response Headers | response-header-name: response-header-value1, response-header-value2, ... Accept-Ranges: bytes Connection: keep-alive If Response message body exists: Content-Type: text/plain |
| - | BLANK LINE |
| Response Message Body | XML Data (Conditional) |
Note: Requirements for Bad format checks are further discussed in Section A.6.2 General - Bad Request Format.
Sample Exchange
GET / HTTP/1.1
Message: STXN
Host: localhost:8080
Connection: keep-alive
HTTP/1.1 200 OK
Date: Wed, 18 Oct 2017 08:56:53
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 116
Content-Type: text/plain
<Configuration Test_ID="T_001"><Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000001</Tag></Configuration>
POST / HTTP/1.1
Message: ETXN
Host: localhost:8080
Connection: keep-alive
Content-Length: 140
Content-Type: text/plain
<Transaction_Details><Test_ID>T_0001</Test_ID><Transaction_Outcome>20</Transaction_Outcome><AcquirerData/><IRWINData/></Transaction_Details>
HTTP/1.1 200 OK
Date: Wed, 18 Oct 2017 08:57:14
Accept-Ranges: bytes
Connection: keep-alive
A.3 Start of Transaction (STXN)
STXN is a message sent by the Reader Controller to the Test Tool to indicate that the reader-terminal is ready to start a transaction. Reader-Terminal configuration is sent back as the message response.
HTTP Request
| Entity | Description | Comments |
|---|---|---|
| Request Liune | GET/HTTP/1.1 | Use GET method |
| Request Headers | Message: STXN Host: [IP Address]:[Port] Connection: keep-alive |
- |
HTTP Response
| Entity | Description | Comments |
|---|---|---|
| Status Line | HTTP/1.1 [status-code reason-phrase] | status-code reason-phrase:
|
| Response Headers | Connection: keep-alive Content-Type: text/plain |
- |
| Resonse Message Body | XML Data | XML Data that contains the Reader-Terminal Configuration in order to perform the test. See Companion Guide for the XML content. |
A.4 End of Transaction (EXTN)
ETXN is a message sent by the Reader Controller to the Test Tool to indicate that the transaction in the reader-terminal has completed. The Transaction outcome details is submitted to the server as part of the message request.
HTTP Request
| Entity | Description | Comments |
|---|---|---|
| Request Line | POST/HTTP/1.1 | Use POST method |
| Request Headers | Message: EXTN Host:[IP Address]:[Port] Connection:keep-alive Content-Type: text/plain |
- |
| Request Message Body | XML Data | XML Data that contains the transaction outcome details. See tables A-1: Sample <Transaction_Details> and A-2: XML Elements and Attributes within <Transaction_Details> |
HTTP Response
| Entity | Description | Comments |
|---|---|---|
| Status Line | HTTP/1.1 [status-code reason-phrase] | status-code reason-phrase:
|
Note: A 200 status code is merely an acknowledgement response of the message regardless whether the test case verdict is a pass or fail.
Sample <Transaction_Details>
<Transaction_Details>
<Test_ID>T_001</Test_ID>
<Transaction_Outcome>20</ Transaction_Outcome >
<AcquirerData>
<DE_9F02>000000000200</DE_9F02>
<DE_9F03>000000000000</DE_9F03>
<DE_9F26>1122334455667788</DE_9F26>
<DE_82>0020</DE_82>
<DE_9F36>0001</DE_9F36>
<DE_5F34>00</DE_5F34>
<DE_9F7C>010203040500FF</DE_9F7C>
<DE_9F6E>20400000</DE_9F6E>
<DE_9F10>06011203A00000</DE_9F10>
<DE_9F39>07</DE_9F39>
<DE_9F1A>0840</DE_9F1A>
<DE_TERMINAL_ENTRY_CAPABILITY>05</DE_TERMINAL_ENTRY_CAPABILITY>
<DE_95>0000000000</DE_95>
<DE_5F2A>0840</DE_5F2A>
<DE_9A>180521</DE_9A>
<DE_9C>00</DE_9C>
<DE_9F37>11223344</DE_9F37>
<DE_9F5B/>
<DE_9F24/>
<DE_57>4761739001010010D20122011234599999991F</DE_57>
</AcquirerData>
<IRWINData/>
</Transaction_Details>
Table A-2: XML Elements and Attributes within <Transaction_Details>
| XML Element / Attribute | Description | Presence | Example Value |
|---|---|---|---|
| Transaction_Details | Container element for Transaction Details below static elements (always present):
|
Mandatory | - |
| Test_ID | Contains the Unique Identifier of the test case Note: This shall reflect the equivalent test case ID as received from the STXN message. Otherwise, the server shall decline acknowledgement of ETXN message. |
Mandatory | T_001 |
| Transaction_Outcome | Contains a 1-byte representation of the Transaction Outcome in Hex String format. This byte is reset to 0x00 at the beginning of a transaction. The left nibble of the byte indicates the transaction outcome (bits 8-5)
The right nibble of the byte indicates the reader-terminal verification results (bits 4-1)
Note: Reader-terminal verification results (bits 4-1) are to be populated when transit feature is supported and enabled (if TTQ B1b1 is set to 1b – Transit). |
Mandatory | 04, 06, 20, 30, E0, F0… |
| Additional_Output | Contains a 1-byte representation of the Transaction Information in Hex String format. This data carries an extended information of the Transaction Outcome. This byte is reset to 0x00 at the beginning of a transaction. The left nibble of the byte indicates the additional transaction information (bits 8-6)
|
Mandatory for VCTKS Test Plan only; NA for other test plans | 00, 80, 20… |
| DE_<tag> | DE element that represents a tag and value in a list. | Conditional | <DE_9F02>000000000200</DE_9F02> |
| AcquirerData | Container element for data elements that are available to the acquirer for inclusion in online messages and clearing records. The reader-terminal is not prohibited from providing other data in addition to the minimum data specified in the list. Acquirer Data shall be populated for all Offline Approval, Offline Decline, Online Approval and Online Decline transactions. See Table A-3 for the list of Data Elements to be populated. Note: For Switch and/or Terminate transactions this shall be an empty container element |
Mandatory | -- |
| IRWINData | The element is no longer in use but kept for completeness | Mandatory | -- |
A.4.1 XML Elements within <AcquirerData>
There is a set of XML Element tags that are minimally required to be included in <AcquirerData> container element. Refer to the specific Companion Guide for the relevant list of tags.
A.5 ECHO
ECHO is an administrative message for the Reader Controller to check the end-to-end communication between the client and the server
HTTP Request
| Entity | Value | Comments |
|---|---|---|
| Request Line | **TRACE / HTTP/1.1 ** | Use TRACE method |
| Request Headers | Message: ECHO Host: [IP Address]:[Port] Connection: keep-alive |
- |
HTTP Response
| Entity | Value | Comments |
|---|---|---|
| Status Line | HTTP/1.1 [status-code reason-phrase] | status-code reason-phrase 200 OK (success, ACK) 400 Bad Request Format (malformed request syntax) 408 Request Timeout (server is busy, try again later) Others (fail) |
| Response Headers | Connection: keep-alive Content-Type: text/plain |
- |
| Response Message Body | [Content of the HTTP Request header(s)] | Echoes back the content of the HTTP Request headers |
A.6 Scenarios and Error Handling
A.6.1 General - No Host Response
When a test process begins, Server socket connection shall always be available to the client throughout the duration of the process. Client shall be able to handle when there is no host/server response. This indicates connection failure with the host.
A.6.2 General - Bad Request Format
The Server shall check the message syntax when it receives message from the client (e.g. bad or missing expected request header “Message”). Server shall return 400 Bad Request Format status code, which indicates that the request syntax is malformed.
Message syntax check shall include the following conditions. In the event that any of below condition is not met, the server shall return 400 Bad Request Format:
-
Header Message value shall not be null and shall be equal to “STXN”, “ETXN” or “ECHO” (case-sensitive).
-
ETXN request Message body content shall not be null, and shall contain all following key words (case-sensitive)
- <Transaction_Details>
- </Transaction_Details>
- <Test_ID>
- </Test_ID>
- <Transaction_Outcome>
- </Transaction_Outcome>
The following is only valid and mandatory for VCTKS Implementation:
- <Additional_Output>
- </Additional_Output>
-
ETXN request Test ID received should be the same value as the current Test ID (case-sensitive) or the Test ID sent from the last STXN response.
A.6.3 General - Server Busy, Request Timeout
When a client sends a message and the Server is Busy, a 408 Request Timeout status code shall be returned. This indicates that the server is busy and the client can try to re-send the same message later.
Recommended Settings (Below setting constitutes a total of 5 minutes of retries – allows the human tester to view the visual checks and respond accordingly. This setting must be configurable at client side.)
- Delay: 1 second
- Number of retries: 300
Note: For status codes other than 408, automatic retry is not applicable.
A.6.4 General - Error Message
If the status code is not 200 or not 204 or 408 and the number of retries are exhausted (if applicable) then the client shall indicate an error message displaying minimally the “status-code reason-phrase” to the user and terminate the testing process.
A.6.5 Connection and Messaging Protocol Test
A 200 status code for TRACE, Echo means network connection and messaging protocols are both ok. Status code other than 200 indicates further troubleshooting is required.
A.6.6 Test Execution
Below flow summarizes the client-server message exchange during a test execution. Before the test process starts, the server shall prepare the list of Test_IDs to run. The list of Test_IDs to run depends on the type of run the Test Tool user prefers:
a. Single run – execute a single test case (run-one-by-one)
b. Batch run – execute the full batch of test cases (run-full-batch)
A Test_ID shall adapt a test cycle that minimally consists of three states:
- begin – the beginning state, where the Test_ID have never been sent or have never been completed.
- sent – the sent state is where the server receives a Start-of-Transaction message and this Test_ID have been sent to the client.
- completed – the completed state is when the server receives an End-of-Transaction message for the Test_ID and the response status code is 200 (OK).
When the server has exhausted the list of Test_IDs (i.e. no more test case to run), the server shall respond Start-of-Transaction message with 204 status code.
a. Single Run
b. Batch Run
A.6.7. Test Execution - Stop on Error
The test tool shall have an option for users to enable the Stop-On-Error function. This functionality enables the Test Tool to “pause” the test process when Product-under-test has failed a test. This enables the user to investigate the cause of failure before resuming the test process. When a test process is paused, the test tool shall memorize the test case context so that the process can continue to the next test case when resumed.
When Stop-On-Error function is enabled and a verdict for the last test case is a FAIL, the server shall reply with a 204 status code.
Note: If the test verdict is not yet available (this is true for some test cases that requires extra Visual Check(s)), the server may reply with “Server is Busy” 408 return code. See Appendix A.6.3.
A 204 status code shall make the client application stop or pause the test process. When the client application starts again the test process, the server shall respond with the next Test_ID with state == begin.
A.6.8 Multiple Start of Transaction (STXN) Messages
Below illustration shows the expected server behavior when multiple STXN message is received. In this case, the server shall respond with the last Test_ID in “sent” state.
A.6.9 Multiple End of Transaction (ETXN) Messages
Below illustration shows the expected server behavior when multiple ETXN message is received. In this case, the server shall check that the Test_ID is the same with the last Test_ID (where last message is ETXN message). If the Test_ID is the same, the server shall overwrite the transaction outcome from the new ETXN message and shall invoke the Test Tool to re-do validation of the test.
A.6.10 End of Transaction (ETXN) Message with Wrong Test_ID
When the server receives an ETXN message, it shall validate that the Test_ID match the last Test_ID (from the last STXN message or last ETXN message). If it does not match, the server shall reply with 400 status code (Bad Request Format).
A.6.11 Echo in Between Messages
Echo is an administrative message to test end-to-end client-server communication. Test case or test process shall not be affected in any way by an Echo message.
A.6.12 Unexpected Flow of Message
When an incoming message is unexpected by the server (i.e. End-of-Transaction message is received for a Test_ID when test state==begin) the server shall reply 400 status code (Bad Request Format).
Appendix B Reader Status and Event
B.1 Outcome Events
| Status/Event | Description |
|---|---|
| EVT_NOTIFY_OUTCOME_APPROVED | The reader shall indicate to the cardholder and merchant that the transaction has been approved. |
| EVT_NOTIFY_OUTCOME_DECLINED | The reader shall decline the transaction and indicate to the cardholder and merchant that the transaction has been declined. |
| EVT_NOTIFY_SWITCH_INTERFACE | If the reader supports another interface, the reader shall prompt to insert or swipe card |
| EVT_NOTIFY_TERMINATE | The reader (or terminal) shall clearly communicate to the cardholder and merchant the outcome of the transaction - Terminate |
| EVT_NOTIFY_SWITCH_OR_TERMINATE | Either of the behavior described for below events is acceptable:
|
| EVT_NOTIFY_OUTCOME_DECLINED_OR_GO_ONLINE | Either of the behavior described for below events is acceptable:
|
| EVT_NOTIFY_ANY_COMPLETION_OUTCOME | The reader shall indicate any transaction completion outcome (Approved or Declined). The reader shall not indicate any error or terminate the transaction. |
| EVT_NOTIFY_ANY_COMPLETION_OUTCOME_OR_TERMINATE | The reader shall indicate any transaction completion outcome (Approved or Declined) or Terminate. |
B.2 Other Events
| Status/Event | Description |
|---|---|
| EVT_UNIQUE_UN_GENERATED | The kernel shall use a unique Unpredictable Number (tag '9F37') for this transaction. NOTE: Tool Vendor may provide a means to supply user with the Unpredictable Number from the Test Session for this check. |
| EVT_REQUEST_PRESENT_CARD | The reader shall request for card to be presented |
| EVT_REMOVE_CARD_IN_PROGRESS | The reader shall indicate to the cardholder and merchant that card read is complete and that the card may be removed, but that the transaction is still in progress. |
| EVT_REFER_TO_PAYMENT_DEVICE | The reader shall indicate to the cardholder to refer to their payment device for further instructions and immediately power down the contactless interface. After a duration of between 1000ms and 2000ms, the reader shall power up the contactless interface and return to Discovery Processing.Any message displayed to the cardholder shall continue to be displayed during the subsequent Discovery Processing. |
| EVT_NOTIFY_DISPLAY_AMOUNT | The reader shall display the Amount, Authorized (tag 9F02) when prompting for a card to be presented. |
| EVT_SECOND_TAP_PERFORMED | The reader shall prompt the cardholder to (re)present their contactless card for Issuer Update Processing, and Discovery Processing shall be performed. |
| EVT_SECOND_TAP_NOT_PERFORMED | The reader shall not prompt the cardholder to (re)present their contactless card for Issuer Update Processing. |
| EVT_ONLINE_PIN_PERFORMED | Verify that the Online PIN processing is performed |
| EVT_ONLINE_PIN_NOT_PERFORMED | Verify that the Online PIN processing is not performed |
| EVT_SIGNATURE_ACQUIRED | Verify that the Signature is acquired |
| EVT_SIGNATURE_NOT_ACQUIRED | Verify that the Signature is not acquired |
| EVT_AOSA_DISPLAYED | At the transaction completion, verify that the Available Offline Spending Amount (AOSA) is displayed by the reader Note: As information to the user, a 6-byte HEX value is appended together with this event name. This value is unformatted AOSA value and shall be displayed by the Test Tool for user validation. e.g. “EVT_AOSA_DISPLAYED = 000000000100” ($1.00) |
| EVT_AOSA_NOT_DISPLAYED | At the transaction completion, verify that the Available Offline Spending Amount (AOSA) is not displayed by the reader |
| EVT_AOSA_PRINTED | Verify that the Available Offline Spending Amount (AOSA) is printed by the reader Note: As information to the user, a 6-byte HEX value is appended together with this event name. This value is unformatted AOSA value and shall be displayed by the Test Tool for user validation. e.g. “EVT_AOSA_PRINTED = 000000000100” ($1.00) |
| EVT_AID_PRINTED | Verify that the Application Identifier (AID) value is fully printed as hexadecimal characters by the reader Note: As information to the user, a HEX value is appended together with this event name. This value is the expected AID to be printed and shall be displayed by the Test Tool for user validation. e.g. “EVT_AID_PRINTED = A0000000031010080910” |
| EVT_RF_FIELD_ON | The reader is expected to power on the RF field at this specific test instruction. Lab to verify that the RF field is active. |
| EVT_RF_FIELD_OFF | The reader is expected to power off the RF field at this specific test instruction. Lab to verify that the RF field is non active. |
| EVT_FDDA_VERIFICATION_NOT_PERFORMED | The transit kernel shall indicate that Fast Dynamic Data Authentication (fDDA) verification is not performed. |
| EVT_FDDA_VERIFICATION_PERFORMED_AND_SUCCESSFUL | The transit kernel shall indicate that Fast Dynamic Data Authentication (fDDA) verification is performed and successful. |
| EVT_FDDA_VERIFICATION_PERFORMED_AND_FAILED | The transit kernel shall indicate that Fast Dynamic Data Authentication (fDDA) verification is performed and failed. |
| EVT_APPLICATION_EXPIRED | The transit kernel shall indicate that the Card Application is expired. |
| EVT_APPLICATION_NOT_EXPIRED | The transit kernel shall indicate that the Card Application is not expired. |
| EVT_ONLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_1b | The transit kernel shall indicate that Online Required by Reader Indicator is set to 1 |
| EVT_ONLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_0b | The transit kernel shall indicate that Online Required by Reader Indicator is set to 0 |
| EVT_DECLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_1b | The transit kernel shall indicate that Decline Required by Reader Indicator is set to 1 |
| EVT_DECLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_0b | The transit kernel shall indicate that Decline Required by Reader Indicator is set to 0 |
| EVT_APPLICATION_PAN_ON_TERMINAL_EXCEPTION_FILE | The transit kernel shall indicate that the Card Application PAN is present on the Terminal Exception File |
| EVT_APPLICATION_PAN_NOT_ON_TERMINAL_EXCEPTION_FILE | The transit kernel shall indicate that the Card Application PAN is not present on the Terminal Exception File |
B.3 Checks
| Check | Description |
|---|---|
| CHK_EXP_ACQ_DATA | Perform check to match the expected output data objects. Acquirer Data refers to the data objects for possible inclusion to Online Authorization Message and/or Clearing Message to the Acquirer. Only the content is required to be matched (whether the data shall be present or shall not be present and if present shall be matched). The actual messaging protocol is out of scope from this document. The user needs to perform visual check to match the expected <AcquirerData> container element as listed within the Test Instructions. See section 4.4 |
| CHK_APDU_LOG | Perform check on the APDU log. APDU log refers to the message exchange unit between the “Card” smart card emulation and the smart card Reader referred here as APDU (Application Protocol Data Unit). The user needs to perform visual check on the APDU log as described in the Test Instruction; Step element; Description attribute. See section 4.4 Note: This check is only present in Manual Test Plan |
Sample content of Test Instruction with CHK_EXP_ACQ_DATA
<Test_Instruction>
<Step Description="Verify the completeness and accuracy of mandatory data elements and conditional data elements (if present) sent to the acquirer">
<Check>CHK_EXP_ACQ_DATA</Check>
<AcquirerData>
<DE_9F39>07</DE_9F39>
<DE_9F10>06011203900000</DE_9F10>
<DE_9F1A>0840</DE_9F1A>
<DE_9A>170601</DE_9A>
<DE_9C>00</DE_9C>
<DE_9F26>Match actual value with APDU data</DE_9F26>
<DE_9F36>0001</DE_9F36>
<DE_9F37>Match actual value with APDU data</DE_9F37>
<DE_9F5B/>
<DE_82>2020</DE_82>
<DE_9F6E>20400000</DE_9F6E>
<DE_9F02>000000000200</DE_9F02>
<DE_5F2A>0840</DE_5F2A>
<DE_9F03>000000000000</DE_9F03>
<DE_9F7C/>
<DE_5F34>00</DE_5F34>
<DE_9F24/>
<DE_95>0000000000</DE_95>
<DE_57>4761739001010010D20126211234599999991F</DE_57>
<DE_TERMINAL_ENTRY_CAPABILITY>05|08</DE_TERMINAL_ENTRY_CAPABILITY>
</AcquirerData>
</Step>
</Test_Instruction>
Sample content of Test Instruction with CHK_APDU_LOG
<Test_Instruction>
<Step Description="Verify the Transaction Date (tag '9A') in GPO is set to: February 29, 2012">
<Check>CHK_APDU_LOG</Check>
</Step>
</Test_Instruction>
Appendix C Keys Information
C.1 ICC Private Keys
icc_keys.xml file contains the RSA ICC Private Keys to be used by Card Emulation for dynamic calculation of Signed Dynamic Application Data (SDAD) (Mandatory). ECC ICC keys are included for dynamic Card Key Generation in Kernel 8 transaction.
Sample content of icc_keys.xml:
<Keys>
<ICC_Key>
<ICC_Key_Set ID="RSA_ICC_TEST_KEY_512_EXP03" Type="RSA" >
<ICC_Private_Key>751D213A05AAD6573…</ICC_Private_Key>
<ICC_Key_Modulus>AFABB1D708804182CB9…</ICC_Key_Modulus>
<ICC_Key_Public_Key_Exponent>03</ICC_Key_Public_Key_Exponent>
<ICC_Key_CRT_constant_q-1_mod_p>383C27E727986020…</ICC_Key_CRT_constant_q-1_mod_p>
<ICC_Key_CRT_constant_d_mod_q-1>787CDEC6FFA37BD…</ICC_Key_CRT_constant_d_mod_q-1>
<ICC_Key_CRT_constant_d_mod_p-1> A5E3357BFFE4861….</ICC_Key_CRT_constant_d_mod_p-1>
<ICC_Key_CRT_constant_prime_factor_q>B4BB4E2A7F75…</ICC_Key_CRT_constant_prime_factor_q>
<ICC_Key_CRT_constant_prime_factor_p>F8D4D039FFD6…</ICC_Key_CRT_constant_prime_factor_p>
</ICC_Key_Set >
<ICC_Key_Set ID="ECC_ICC_P256_01" Type="ECC" >
<ECC_Curve>P-256</ECC_Curve>
<ICC_ECC_Private_Key>C2664099EABBB9000A37743…</ICC_ECC_Private_Key>
<ICC_ECC_Public_Key_X>FC9E6815688C5B84CFEF…</ICC_ECC_Public_Key_X>
<ICC_ECC_Public_Key_Y>2B9E14FEFB5A14F3EE11…</ICC_ECC_Public_Key_Y>
</ICC_Key_Set >
</ICC_Key>
</Keys>
| XML Element/Attribute | Description | Requirement | Example Value |
|---|---|---|---|
| Keys | Root element | Mandatory | -- |
| ID | Attribute identifier of a key | Mandatory | “UDK_1”, “RSA_ICC_TEST_KEY_512_EXP03” |
| ICC_Key | Container element for all RSA/ECC keys | Mandatory | -- |
| ICC_Key_Set | Container element for single RSA key. Multiple < ICC_Key_Set > may be present under <ICC_Key> | Mandatory | -- |
| Type | Attribute that provides the Key Set Type to distinguish a “RSA” or “ECC” Key Set. If the attribute is not present, it signifies that the Key Set is of “RSA” type. | Conditional | “RSA”, “ECC” |
| ICC_Private_Key | Private Key | Mandatory for RSA Key Type | 751D213A05AAD657326A379158EFE8E051C94C61C34A01ACC617E74C8D3010E8A529B48A1D59F6448AC8AE0A356B9C0A3AF44E5FA084E2F9FF2FE8055B6D516B |
| ICC_Key_Modulus | - | Mandatory for RSA Key Type | AFABB1D708804182CB9F535A0567DD507AADF292A4EF02832923DAF2D3C8195EA54EAD33AB52F4552CAFA3DBEB5993CC1EF9F03A499E19A4D96834EEAD06CC2D |
| ICC_Key_Exponent | - | Mandatory for RSA Key Type | 03 |
| ICC_Key_CRT_constant_q-1_mod_p | - | Mandatory for RSA Key Type | 383C27E727986020428BC67F30A63E4BEC61EDB8815A2C4B37FABA60B93C4980 |
| ICC_Key_CRT_constant_d_mod_q-1 | - | Mandatory for RSA Key Type | 787CDEC6FFA37BD50713D88FD1E1755F5BC84123C3F6C2803C53F38D28D68E5B |
| ICC_Key_CRT_constant_d_mod_p-1 | - | Mandatory for RSA Key Type | A5E3357BFFE4861F3698914DEAEEA673D33F65F8CC986B9E556C47B7446B5303 |
| ICC_Key_CRT_constant_prime_factor_q | - | Mandatory for RSA Key Type | B4BB4E2A7F7539BF8A9DC4D7BAD2300F09AC61B5A5F223C05A7DED53BD41D589 |
| ICC_Key_CRT_constant_prime_factor_p | - | Mandatory for RSA Key Type | F8D4D039FFD6C92ED1E4D9F4E065F9ADBCDF18F532E4A16D80226B92E6A0FC85 |
| ECC_Curve | - | Mandatory for ECC Key Type | P-256 |
| ICC_ECC_Private_Key | Card private key used in Elliptic Curve Blinded Diffie Hellman to establish SKC, SKI | Mandatory for ECC Key Type | C2664099EABBB9000A37743CD01B7EA47D660F476CE7FCED2EBB04C7C8B4E57B |
| ICC_ECC_Public_Key_X | Card public key used in Elliptic Curve Blinded Diffie Hellman to establish SKC, SKI, x coordinates | Mandatory for ECC Key Type | FC9E6815688C5B84CFEFF097055F01E9EDCAB4DC85B675F6CC989D1078EB48BB |
| ICC_ECC_Public_Key_Y | Card public key used in Elliptic Curve Blinded Diffie Hellman to establish SKC, SKI, y coordinates | Mandatory for ECC Key Type | 2B9E14FEFB5A14F3EE117F59F9CA9C307C2913E40250B41AD76EB1D592A8E373 |
C.2 CA Keys
ca_keys.xml file contains the CA Keys to be used by the Reader/Terminal for Offline Data Authentication (ODA).
Sample content of ca_keys.xml:
<Keys>
<CA_Public_Key Index="51">
<CA_Public_Key_Modulus>DB5FA29D1FDA8C1634B04DCCFF148ABEE63C772035C79851D3512107586E02A917F7C7E885E7C4A7D529710A145334CE67DC412CB1597B77AA2543B98D19CF2CB80C522BDBEA0F1B113FA2C86216C8C610A2D58F29CF3355CEB1BD3EF410D1EDD1F7AE0F16897979DE28C6EF293E0A19282BD1D793F1331523FC71A228800468C01A3653D14C6B4851A5C029478E757F</CA_Public_Key_Modulus>
<CA_Public_Key_Exponent>03</CA_Public_Key_Exponent>
</CA_Public_Key>
</Keys>
| XML Element/Attribute | Description | Requirement | Example Value |
|---|---|---|---|
| Keys | Root element | Mandatory | -- |
| CA_Public_Key | Container element that represents a single CA key. Multiple of <CA_Public_Key> may be present under |
Mandatory | -- |
| Index | Attribute index of a CA Public key | Mandatory | 51 |
| CA_Public_Key_Modulus | CA Public Key Modulus | Mandatory | DB5FA29D1FDA8C1634B04DCCFF148ABEE63 C772035C79851D3512107586E02A917F7C7E 885E7C4A7D529710A145334CE67DC412CB1 597B77AA2543B98D19CF2CB80C522BDBEA0 F1B113FA2C86216C8C610A2D58F29CF3355CE B1BD3EF410D1EDD1F7AE0F16897979DE28C 6EF293E0A19282BD1D793F1331523FC71A2288 00468C01A3653D14C6B4851A5C029478E757F |
| CA_Public_Key_Exponent | CA Public Key Exponent | Mandatory | 03 |
Appendix D Additional Information
This section provides any other information required by the tool vendors for test development considerations.
D.1 Regression List
regression_list.xml contains the list of test cases in scope to test for regression. This list is only used when the product-under-test is allowed to run in regression mode. When a product is allowed to run in regression mode, the test tool shall use regression_list.xml instead of the full test plan list to do the Test Case Filtering and Test Execution as discussed in Section 3 Test Case Filtering and Section 4 Test Case Execution.
D.2 TermSIM Configuration
sim_config_list.xml is used by the TermSIM to perform automatic configuration of its internal feature options. The file is for reference only and is not to be used by the test tool.
Appendix E Kernel 8
This section describes the preparation of the terminal if Kernel 8 is supported.
E.1 Kernel 8 Configuration
All the mandatory configuration data objects listed in C8 must be present in the product supporting Kernel 8 (K8).
The Test Plan does not require additional Reader Controller (RC) configuration for parameters that are specific only to K8.
Existing defined RC configurable parameters, which are applicable to K8 processing, shall remain valid and applicable to the K8 configuration. Likewise, configurations sent via the RC to update parameters which are not applicable or not supported by Kernel 8 processing shall be ignored.
Apart from the RC configurable parameters, Test Plan does not restrict other K8-specific configurations, with the exception of the data objects listed below. These data objects shall be configured as follows throughout the Test Plan, aligning to Visa recommended configuration. This is to ensure Kernel 8 transactions can be satisfied as per Test Plan expectation:
- Terminal Type, Tag ‘9F35’: Shall be ‘Online’ capable
- Tags To Read, Tag ‘9F8203’: Shall be absent.
- Data Envelopes To Write, Tag ‘BF8104’: Shall be absent
- Proceed To First Write Flag, Tag ‘9F8202’: Shall be absent
Appendix F Report XML File
This section complements the description for the Report XML file that is used for Test Case Filtering Report Generation 3.6 Visa Test Case Filtering Report Generation.
F.1 Using XML Tables
Each Table is used to describe the XML structure of the file formats and the Table comprises of four main columns:
| Element/Node (1|2|3|4) | Occurrence (Min..Max) | Description | Content ([Condition]: DataType | Parameter | Value) / Example (e.g.) |
|---|
- Element/Node: Describes the XML elements residing in respective nodes of the XML hierarchical structure. "1" indicates the Root node of the XML and the subsequent numbers represent the child nodes in hierarchical order.
- Occurrence: Describes the occurrence of the XML element within its indicated node and is used to facilitate schema check. ”Min” indicates the minimum occurrence required and ”Max” indicates the maximum occurrence allowed. For example:
- 1..1 : Element is mandatory and can only occur once.
- 0..1 : Element is optional and if present, can only occur once.
- 1..var : Element is mandatory and can occur more than once.
- 0..var : Element is optional and can occur more than once.
Note: The occurrence rule is bound to its parent element. If the parent element is not present or is empty, the occurrence rule for the child elements will not apply.
- Description: Describes the XML element and additional conditions if any.
- Content/Example: Describes the Content of the XML element (Attributes and/or Text Content) and provides Example of how the XML element would be crafted.
The Content is represented in format: “[Condition]: DataType | Parameter | Value”, where
- ”Condition” defines if the Text Content or Attribute is [M] = Mandatory, [C] = Conditional or [O] = Optional.
- For Text Content, only [M] is used to mandate that the Text Content must not be empty. [C] indicates that the presence of Text Content is dependent on other indicators (described specifically for each element), and [O] indicates that Text Content is optional. It is acceptable that Text Content defined as [C] and [O] indicates an empty element tag.
- For Attributes, only [M] is used to mandate that the attribute must be present. [C] indicates that the presence of attribute is dependent on other indicators (described specifically for each attribute)
- ”DataType” defines the data type of the Attribute/Text Content. ”Parameter” and ”Value” are used for Attributes.
- ”Parameter” defines the name of the Attribute.
- ”Value” (if used) defines the absolute value of the Attribute.
- ”Condition” defines if the Text Content or Attribute is [M] = Mandatory, [C] = Conditional or [O] = Optional.
Attributes Example:
- [M]: String | Tag | "Name": Element has an Attribute "Tag" with a "String" Data Type and the Attribute Value is defined to be "Name".
- [O]: String | ID: Element may have an Attribute "ID" with a "String" Data Type. The Attribute Value is not defined.
Text Content Example:
- [M]: String: Element must not have an empty Text Content and the Text Content is of Data Type "String".
- String: Element records a Text Content of Data Type "String".
F.2 Data Types in XML Tables
This table defines the data types used in the XML tables.
| Type | Base Type | Constraints | Description |
|---|---|---|---|
| String | String | - | Stores alphanumeric combination and text. Allows ASCII punctuations and symbols like '['. Includes values "yes" and "no". |
| Boolean | String | true, false | Enumeration field with values "true" or "false" only. |
| Hexadecimal | String | [A-F][0-9] | Hexadecimal representation with no whitespaces and in all uppercase. |
| Decimal | Numeric | -- | Represents decimal numbers with arbitrary lengths. Examples: "5.0", "1.16", "1". |
| Integer | Numeric | -- | Represent whole numbers with no fractional parts. Examples: "0", "1", "2". |